DTS recommended that we post this question in the Developer Forums.
We would like clarification on the supported production behavior of originalTransactionId in the App Store Server API, particularly after a subscription expires and the customer resubscribes.
Our main backend design question is: Can we continue using a stored originalTransactionId to identify and retrieve subsequent subscription activity within the same subscription group, or must we support discovering and associating new identifiers?
Integration context
Our backend uses:
GET /inApps/v1/subscriptions/{transactionId}
GET /inApps/v2/history/{transactionId}
App and subscription details:
Bundle ID: com.lgeha.nuts
Subscription group identifier: 22350255
Product A: thinq_g_unlimitedpro
Product B: thinq_g_single
We use originalTransactionId as a key for subscription records and associate those records with user accounts in our service. We do not use it as an identifier for the Apple Account itself.
Please assume the same Apple Account and app, with both products in the same subscription group, using ordinary auto-renewable subscriptions without a special subscription migration.
This question concerns the identifiers and lookup behavior exposed to our backend by the App Store Server API.
Sandbox observation and scope
During sandbox testing, purchase history was cleared, and a new originalTransactionId was subsequently observed.
We understand that this observation involved a sandbox history reset and does not establish production behavior. Our questions below concern production behavior without any purchase-history reset.
Preservation across subscription lifecycle events
For each scenario below, is originalTransactionId guaranteed to remain unchanged for subsequent transactions, or can Apple assign a different value?
Automatic renewal of the same product.
An upgrade, downgrade, or crossgrade between products A and B while the subscription is active.
Turning off automatic renewal, then re-enabling it before expiration.
Turning off automatic renewal, allowing the subscription to expire, and later resubscribing to the same product.
Turning off automatic renewal for product A, allowing it to expire, and later subscribing to product B within the same subscription group.
Scenarios 4 and 5 are our primary concern. We would like to distinguish commonly observed behavior from supported guarantees that a backend can rely on.
Conditions for a new identifier after expiration
For scenarios 4 and 5, can a new purchase legitimately receive a different originalTransactionId in production despite the Apple Account, app, and subscription group remaining unchanged?
If so, what conditions determine this? Does it depend on:
Time elapsed since expiration.
Billing retry or billing grace-period status or history.
Whether the purchase uses StoreKit 1 or StoreKit 2.
Whether the customer resubscribes inside the app or through App Store subscription management.
Our concern is whether these factors affect the identifiers subsequently returned by the App Store Server API.
Stability of an existing transaction
Separately from a new purchase receiving a new identifier, if the same transactionId is retrieved at two different times, is its associated originalTransactionId guaranteed to remain unchanged?
Can an Apple-supported correction process change that association, or should such a result be treated as an inconsistency and reported through Feedback Assistant?
This question concerns the same returned transactionId, rather than a different latest transaction returned by a subsequent status query. We have not confirmed such a change in production.
Lookup behavior using a previously stored identifier
If resubscription can create a new originalTransactionId, how does that affect each endpoint?
For GET /inApps/v1/subscriptions/{transactionId}:
Can a request using the previous originalTransactionId return the current status of a later resubscription with a different originalTransactionId, assuming the same Apple Account, app, and subscription group? Or must the backend obtain the new identifier separately?
For GET /inApps/v2/history/{transactionId}:
Can a request using the previous originalTransactionId return transactions from that later resubscription, assuming all applicable pages are retrieved and no filters exclude those transactions?
Please clarify any endpoint-specific guarantees or limitations on using an older identifier to discover subsequent subscription activity.
Backend account association
If resubscription can create a new identifier, should our backend support multiple originalTransactionId values for one service user within the same subscription group?
Is there a documented server-side relationship that links subscriptions with different originalTransactionId values? Alternatively, should that association rely on an application-managed identifier such as appAccountToken, where available?
Please clarify any limitations, especially for resubscriptions initiated outside the app.
Related discussions
We reviewed these discussions as background:
Transaction ID Misassociation in IAP Subscription API (https://developer.apple.com/forums/thread/777433)
original_transaction_id associated to web_order_line_item_id of auto-renewable subscription changed (https://developer.apple.com/forums/thread/778301)
We do not assume that these reports establish supported behavior or share the cause of our sandbox observation.
Could Apple clarify the supported preservation or replacement rules, particularly after expiration and resubscription, and point us to documentation describing the behavior a backend can rely on?
If investigating a specific inconsistency requires a separate Feedback Assistant report, please indicate which server-side request and response details should be included.
Thank you.