original_transaction_id information needed in subscription and inconsistent behavior compared with specifications

Inconsistent behavior with the documentation

The Original Transaction ID is determined by the underlying store processing the transaction. As such, it is directly passed on by RevenueCat according to the data provided to us by the store.

In iOS, an original transaction ID is a unique identifier assigned to the very first successful purchase transaction for a product, typically used to track the origin of a subscription or in-app purchase. This ID stays the same for all renewals, restorations, or upgrades within the same subscription group, allowing developers to identify a continuous subscription lifecycle. However, if a user buys a product from a different subscription group, StoreKit generates a new original transaction ID because it represents an entirely separate purchase lineage.

The RevenueCat documentation you shared defines how we define an individual subscription, irrespective of the underlying store. Each subscription in RevenueCat is associated with a RC-specific identifier - this is the “subscription id” in your screenshots and the identifiers prefixed with sub.

Original Transaction ID (OTID) needed in the API V2 Subscription object

We don’t currently provide a way to source the Original Transaction ID via our API. Thanks for your feedback, I’ve shared this with our team for consideration in future API updates.

Events API endpoint

Thanks for this feedback too, I’ve also shared this with our team. To serve a similar use-case, I’d recommend considering daily Scheduled Data Exports which can provide a snapshot of each day’s transactions to a cloud storage bucket in CSV format. This file can be reconciled against your backend which processes the webhooks.

Thank you for your quick answer ​@chris_perriam !

Subscription object

Unfortunately they way you “create” your subscriptions wrapper for Apple Store does not work very well and not predictable enough to use in a synchronization algorithm. When I first looked into this Original Transaction ID (OTID), about half an year ago, from our Sandbox data I noticed that the OTID would not change no matter if user changed the product, cancelled, subscription expired etc. Then, I had a chance to still find the OTID by looking at previous transactions. In recent data, this is not true anymore, the OTID changes or not sometimes even between initial purchase and renewal. Same for RC Subscription object, in regards to Apple purchases, during the lifetime of same package purchase and renewal.

For Google Store this is not a problem. All Subscriptions match the initial purchase, renewals, expiration cycle and at any moment I can infer the OTID from the current transaction ID.

Original Transaction ID via API

We don’t currently provide a way to source the Original Transaction ID via our API. Thanks for your feedback, I’ve shared this with our team for consideration in future API updates.

This is not a new request. Other people here requested for same, months ago. It is really so complicated to expose an additional field to an existing output?

Events API endpoint

I raised this months ago also, and if you search this community posts you will find some requests years back if I am not wrong.

I do not understand why is so hard to expose a data that you already have through a simple API. Events retrieval API endpoint would help with a lot of reconciliation cases. You expose these events already in your admin panel.

Using Scheduled Data Exports it is not good / budget-friendly enough for some scenarios where the product lasts only one week and we want to restore clients subscriptions and access as fast as possible. Also by your documentation it is not guaranteed how up-to-date the export is.

Additional request

Please expose your data in an ordered fashion. This would help in reading and debugging.

Example:

• API Subscriptions list should be ordered by subscription start date.
• CSV Scheduled Data Exports: export the transactions ordered by the transaction date. I have found transactions from October mixed through September transactions.

Thanks ​so much for the feedback @cosmin-ptp, it’s really helpful. I’m sorry you’re having trouble, and I’ve shared your requests with our product team (in addition to what Chris shared previously).