Skip to main content
Solved

Verify Consumables Before Webhook

  • February 24, 2026
  • 4 replies
  • 72 views

Forum|alt.badge.img+2

Hi,

When a user buy a consumable from my app, I need to give them a quota for creating a listing. So it would be better if thats near instant after success purchase.

Thats why i created another route to verify that purchase, grant quota. In case of webhook delays.

But in api endpoints i couldnt get the store identifers of products. Instead i only get RC api id of that product. Since we dont use entitlements i couldnt use any way to get that store ids. I also have a mapping table in my db to get correct quota thats why i need to get that store ids.

 

Am i missing something? 

`https://api.revenuecat.com/v2/projects/${PROJECT_ID}/purchases?store_purchase_identifier=${transactionId}`,

currently i used this one to verify a new purchase.

Best answer by hussain

Hi ​@buluty,

Thanks for reaching out. I’m happy to help.

You’re not missing anything, the v2 purchases endpoint doesn’t embed the store product identifier directly on the purchase object. What you’re seeing there is the RevenueCat product ID reference, and you can use that to look up the store product info.

You have a couple of options on how to proceed:

1. Fetch the Product to get store identifiers

In the purchase response you should have a product_id (or a nested product reference). You can then call: GET https://api.revenuecat.com/v2/projects/{PROJECT_ID}/products/{PRODUCT_ID}.

That product resource contains the store product identifier (the same ID you configured/imported from App Store / Google Play), along with store metadata. You can then use that to hit your own mapping table and grant the correct quota.

2. (Optional) Simplify mapping with RevenueCat product IDs

Since products in RevenueCat are created with the store product identifier as their base ID, you can also key your quota mapping by the RevenueCat product ID instead of the raw store ID.

This can be simpler if:

  • You have the same product ID across stores, or

  • You don’t really need to differentiate iOS vs Android at the quota level.

3. Webhooks / Virtual Currency for quota use-cases (alternative)

For consumables that grant “credits” or “quota”, you may also want to look into:

  • Virtual Currency - lets you map products -> amounts of a virtual currency (e.g. “listings”), then query/update balances via the Developer API instead of maintaining your own quota system. This can reduce how much custom logic you need to maintain.

Hope this helps, let me know if you have any other questions. I’m happy to help.

Best,

Hussain

This post has been closed for comments

4 replies

hussain
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • Answer
  • February 25, 2026

Hi ​@buluty,

Thanks for reaching out. I’m happy to help.

You’re not missing anything, the v2 purchases endpoint doesn’t embed the store product identifier directly on the purchase object. What you’re seeing there is the RevenueCat product ID reference, and you can use that to look up the store product info.

You have a couple of options on how to proceed:

1. Fetch the Product to get store identifiers

In the purchase response you should have a product_id (or a nested product reference). You can then call: GET https://api.revenuecat.com/v2/projects/{PROJECT_ID}/products/{PRODUCT_ID}.

That product resource contains the store product identifier (the same ID you configured/imported from App Store / Google Play), along with store metadata. You can then use that to hit your own mapping table and grant the correct quota.

2. (Optional) Simplify mapping with RevenueCat product IDs

Since products in RevenueCat are created with the store product identifier as their base ID, you can also key your quota mapping by the RevenueCat product ID instead of the raw store ID.

This can be simpler if:

  • You have the same product ID across stores, or

  • You don’t really need to differentiate iOS vs Android at the quota level.

3. Webhooks / Virtual Currency for quota use-cases (alternative)

For consumables that grant “credits” or “quota”, you may also want to look into:

  • Virtual Currency - lets you map products -> amounts of a virtual currency (e.g. “listings”), then query/update balances via the Developer API instead of maintaining your own quota system. This can reduce how much custom logic you need to maintain.

Hope this helps, let me know if you have any other questions. I’m happy to help.

Best,

Hussain


cam
Forum|alt.badge.img+2
  • Helper
  • February 25, 2026

Hi!

 

It seems that RevenueCat abstracts away those IDs since its focus is cross-platform access. If I understand your use case correctly, you need the store ID of the product to identify the quota to return on your db mapping table. Could some of the information returned in the getProducts endpoint be of help? It does not explicitly return the store ID you need, but they could be used to infer it. 

If not, could you update your mapping table and also add a column for the RC ID for that product? I think it might be a cleaner approach to keep track of both the platform ID and the RC ID. 

 

Cam


cam
Forum|alt.badge.img+2
  • Helper
  • February 25, 2026

Reminder to myself to refresh before sending a reply 😆 Thank you for the thorough explanation  ​@hussain! I wasn’t aware of the virtual currency feature


Forum|alt.badge.img+2
  • Author
  • New Member
  • February 25, 2026

Hi ​@buluty,

Thanks for reaching out. I’m happy to help.

You’re not missing anything, the v2 purchases endpoint doesn’t embed the store product identifier directly on the purchase object. What you’re seeing there is the RevenueCat product ID reference, and you can use that to look up the store product info.

You have a couple of options on how to proceed:

1. Fetch the Product to get store identifiers

In the purchase response you should have a product_id (or a nested product reference). You can then call: GET https://api.revenuecat.com/v2/projects/{PROJECT_ID}/products/{PRODUCT_ID}.

That product resource contains the store product identifier (the same ID you configured/imported from App Store / Google Play), along with store metadata. You can then use that to hit your own mapping table and grant the correct quota.

2. (Optional) Simplify mapping with RevenueCat product IDs

Since products in RevenueCat are created with the store product identifier as their base ID, you can also key your quota mapping by the RevenueCat product ID instead of the raw store ID.

This can be simpler if:

  • You have the same product ID across stores, or

  • You don’t really need to differentiate iOS vs Android at the quota level.

3. Webhooks / Virtual Currency for quota use-cases (alternative)

For consumables that grant “credits” or “quota”, you may also want to look into:

  • Virtual Currency - lets you map products -> amounts of a virtual currency (e.g. “listings”), then query/update balances via the Developer API instead of maintaining your own quota system. This can reduce how much custom logic you need to maintain.

Hope this helps, let me know if you have any other questions. I’m happy to help.

Best,

Hussain

Hi Hussain,

Since we already have a website in production and its using its own local payment system, i need my own db and quota system. 

But as you said, currently i do a second api call to products route to get the identifier. And since webhook already sends that identifier i didnt want to create a second mapping id as you mention in option 2.

So option 1 is the one i already doing and so there is no other way. Thats all i wanted to know. 

Thank you for reply.