Clarifications on App Store Server API, StoreKit 1 vs StoreKit 2, and Subscription Notification Handling

Question

Created 4d

Replies 1

Boosts 0

Participants 2

Hi everyone,

We are currently working on improving our subscription backend integration with Apple’s App Store Server API and StoreKit, and had a few questions around StoreKit 1 vs StoreKit 2 behavior and server-to-server notifications.

Looking for clarification on the following points:

/inApps/v1/subscriptions/{originalTransactionId} response compatibility

Does the App Store Server API endpoint /inApps/v1/subscriptions/{originalTransactionId} return consistent response structures for subscriptions created via StoreKit 1 and StoreKit 2, or are there any differences we should account for when parsing the response?

Transaction format in S2S notifications for StoreKit 1 purchases

If a user initially purchases a subscription using StoreKit 1, and the subscription renews later, what transaction format is sent in server-to-server notifications? Does Apple still maintain StoreKit 1 style transaction payloads, or Are they converted into StoreKit 2–style signed transactions?

Validation of signedTransactionInfo and signedRenewalInfo

In App Store Server Notifications V2, the payload includes signedTransactionInfo and signedRenewalInfo. Is there an official Apple API endpoint that can be used to validate these tokens?

Offer / coupon identification from S2S notifications

Can server-to-server notifications reliably indicate which offer was applied (intro offer, promotional offer, or offer code)? If yes, which fields in the transaction payload should be used to identify this?

Trial period identification in StoreKit 2

In StoreKit 1, the field is_trial_period was commonly used to detect free trials. Since this is deprecated in StoreKit 2, which field or transaction property should be used to identify whether a purchase corresponds to a trial period?

Boost

Answer 1

App Store Commerce Engineer OP

Apple

4d

Transactions can be viewed in SK1 or SK2 formats, a transaction doesn’t have an affinity’s the only exceptions are regranted purchases, in SK2 the first transaction id is the only one used to represent the purchase while SK1 will use other transaction ids for each device and upon regrants (identified for auto renewable subs by sharing web order line item id, and all other types by original transaction id).

You pick your format in App Store Connect with deprecated V1 type or V2 notifications.

I recommend the App Store Server Library available in Java Node Python and Swift for Server, the official library which includes validation functions.

It can identify in SK2 style transactions with the offer identifier for all but intro offers, which don’t have an identifier (but offer type will tell you it was used) as well as other metadata fields about it.

0