Clarification on store_transaction_id in CustomerInfo REST API v1

Hi,

I’m happy to clarify this for you.

Depending on the store, store_transaction_id behaves differently:

• Apple: Generates a completely new transaction ID on each renewal.

• Google Play: Generates a new transaction ID on renewal that increments from the original.

• Stripe: Doesn’t generate a unique transaction ID for renewals (it stays the same).

If you need a constant identifier for the life of a subscription, use original_transaction_id—it only changes if the user switches to a different product.

Hope this helps.

Best,

Hussain

So to clarify, the answer in https://community.revenuecat.com/third%2Dparty%2Dintegrations%2D53/what%2Ddoes%2Dstore%2Dtransaction%2Did%2Drefer%2Dto%2Din%2Dcustomerinfo%2Din%2Drest%2Dv1%2Dapi%2D4527?postid=14520#post14520 is not accurate and the `store_transaction_id` field in CustomerInfo object’s `subscriptions.*.store_transaction_id` from v1 REST API does not refer to the `original_transaction_id`

That would be preferred for me yes, but the `CustomerInfo` in v1 REST API, does not contain this value

Hi mskrip,

I find that the response you got from RevenueCat staff incomplete.

Another thing, I believe you should use V2 instead of V1. On a side note, none of the API versions provide clear data and I believe this API would need a version 3 or some other methods added like: transactions list, events list.

Based on the Subscription Data Model definition that you can find on API V2, the store_transaction_id field stores the value of the last transaction_id of your subscription.

A subscription is a collection of all initial and renewal transactions. For instance, if your user purchase a 1 month package and renew this 3 times, the RC subscription model will include these 4 transactions and the store_transaction_id will be the transaction_id of the last renewal.

I recommend you to set up Scheduled Data Exports and to have a look at the transactional data to understand better.

I hope this helps

Hi mskrip,

Thanks for the follow-up—and thanks @cosmin-ptp for the additional context!

Neither API V1 nor V2 returns original_transaction_id directly. Here are a couple of ways you can get it:

1. Webhooks
   Subscription lifecycle events (e.g. INITIAL_PURCHASE, RENEWAL) include original_transaction_id in their payload.
   Docs: https://www.revenuecat.com/docs/integrations/webhooks/event-types-and-fields#subscription-lifecycle-events-fields

2. Scheduled Data Exports
   Exports include original_store_transaction_id, which corresponds to the original transaction ID.
   Docs: https://www.revenuecat.com/docs/integrations/scheduled-data-exports

API V2 Subscriptions Endpoint
/v2/projects/{project_id}/customers/{customer_id}/subscriptions returns store_subscription_identifier—the store’s subscription identifier (e.g. the latest Apple transaction ID or Google Play order ID). It’s not the original ID, but can help verify the current subscription state.
Docs: https://www.revenuecat.com/docs/api-v2#tag/Customer/operation/list-subscriptions

If you let me know what you’re planning to do with the original_transaction_id, I can help pick the best approach.

Hope this helps!

Best,

Hussain

Hello, thanks for the reply ​@hussain , I have both webhooks and Scheduled data exports set up for my project, but neither fit the use case I have for the original_transaction_id :

I want to track usage for a user’s subscription with 30 day periods. The problematic part is transfers of entitlements between user accounts. I want to bind the usage to that specific entitlement (user A uses X/Y in the given period, transfers the entitlement to different user B and I want to still be able to tell that X/Y is already used).

Now, using Scheduled Data exports is obviously not helpful here since, well, that’s scheduled, cannot be checked during runtime.

And as for webhooks, if TRANSFER event contained the original_transaction_id then that could be used but it doesn’t. For now I went with using the store_transaction_id to deduplicate the users, but that’s not perfect either.

Hi mskrip,

What you’re doing—using store_transaction_id to dedupe—is totally understandable given the v1 API’s limits. This is a bit of a tricky case, so here’s an alternative that should give you a truly constant key for each subscription:

• Leverage the Subscription Webhooks

  • Configure the INITIAL_PURCHASE and RENEWAL webhooks in your RevenueCat project. The payload for these webhooks contains the original_transaction_id.

• Persist a Simple Mapping

  • In your own database, store a record like:

    • original_transaction_id → {
        store_transaction_id,
        app_user_id (or entitlement ID),
        [any other metadata you need]
      }

       

  • Do this whenever you handle an INITIAL_PURCHASE or RENEWAL event.

• Dedupe and Track Usage by Original ID

  • When you check usage (or process a TRANSFER event, which doesn’t include the original ID), look up the corresponding original_transaction_id in your mapping and use that as your dedupe key instead of the changing store_transaction_id.

Hopefully this makes sense. Let me know if you have any additional questions.

Best,

Hussain

Thanks Hussain for the detailed suggestion, however keeping such a mapping in the application persistence is not something I would like to fallback to as RC should be the source of truth for these kinds of subscription (meta)data persistence IMO.

For now, I’ll keep using store_transaction_id from the V1 API, and update that if it causes some issues. However, I would very much like to request adding of the original transaction ID value to either of the APIs models if that is possible.

Again, thanks for the help and have a great day