Skip to main content
Solved

Delay in Retrieving Updated Data via V2 Subscriptions API After Webhook Events

  • December 18, 2024
  • 2 replies
  • 107 views
H
Forum|alt.badge.img+2

Hello,

I am working on integrating webhooks to store and update users' subscription statuses on our server.

As suggested in the official documentation (https://www.revenuecat.com/docs/integrations/webhooks#syncing-subscription-status), We’re implementing a system where our server listens to webhook events such as INITIATE_PURCHASE and RENEWAL.

Upon receiving these events, we call the RevenueCat V2 Subscriptions API to retrieve the latest subscription status stored in RevenueCat and update our server data accordingly.

However, in the case of the RENEWAL event, when we call the V2 Subscriptions API immediately after receiving the webhook event, the response often contains outdated information. It seems that we need to wait at least several seconds before calling the API to retrieve the latest data.

To synchronize subscription statuses in an idempotent and robust manner, I agree with the documentation’s suggestion to rely on REST API data rather than directly using the information from webhook events.

Could you provide guidance on how long we should wait after receiving a webhook event before calling the REST API to ensure accurate data retrieval?

Best answer by antonio

Hi ​@heejin-lee-cf2117 ,

 

Apple does renew subscriptions in advance, so we send the renewal events when the renewal happens.

However in the Subscriptions V2 endpoint, we don’t update the period info (`current_period_starts_at`, `current_period_ends_at`) until the new period really starts, but you should be able to see that the subscription has already renewed for the next period looking at the `auto_renewal_status`, which should be `has_already_renewed`.

This mismatch is because RevenueCat events are not based in the V2 models. They will eventually but there’s no concrete timeline yet. 

If you want to get the information that matches the event, I recommend using the V1 Get Customer endpoint , which returns the information used by our SDKs and the one used to generate the events.

 

 

View original
Did this post help you find an answer to your question?
This post has been closed for comments

H
Forum|alt.badge.img+2

FYI)

I am currently testing iOS purchases using the sandbox environment.

The REST API endpoint I am using is: https://api.revenuecat.com/v2/projects/PROJECT_ID/customers/APP_USER_ID/subscriptions 

Additionally, I noticed that the purchased_at_ms value in the RENEWAL webhook event is set to a future timestamp.

I read in the community that this behavior is related to how Apple processes transactions.

Could this be related to the issue where the REST API returns outdated data after receiving a webhook event?

Any guidance on this would be greatly appreciated, particularly regarding how long we should wait after receiving a webhook event to ensure accurate data retrieval via the REST API.

antonio
RevenueCat Staff
Forum|alt.badge.img+4
  • antonio
  • RevenueCat Staff
  • 37 replies
  • Answer
  • December 18, 2024

Hi ​@heejin-lee-cf2117 ,

 

Apple does renew subscriptions in advance, so we send the renewal events when the renewal happens.

However in the Subscriptions V2 endpoint, we don’t update the period info (`current_period_starts_at`, `current_period_ends_at`) until the new period really starts, but you should be able to see that the subscription has already renewed for the next period looking at the `auto_renewal_status`, which should be `has_already_renewed`.

This mismatch is because RevenueCat events are not based in the V2 models. They will eventually but there’s no concrete timeline yet. 

If you want to get the information that matches the event, I recommend using the V1 Get Customer endpoint , which returns the information used by our SDKs and the one used to generate the events.

 

 

H
1 person likes this
  • H
    heejin-lee-cf2117

Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings