Skip to main content

Read-after-write gap between webhook events and /v1/subscribers

  • September 2, 2026
  • 2 replies
  • 95 views
Forum|alt.badge.img+3

Hi, just wanted to give a heads up that I’ve started to see a read-after-write gap between webhook emission and /v1/subscribers, dating to ~Sept 1 14:30 UTC. My server responds to all webhook events by requesting and updating entitlements from /v1/subscribers (as recommended), and after every INITIAL_PURCHASE event I’ve received since then (all from Google Play purchases), the response has had unexpectedly empty entitlements. No code changes on my end and I’ve not seen similar issues previously.

I’ve updated my server to be resilient to this issue, and I’ve also filed a ticket through support with more detailed info on my specific case, but wanted to post this here for a higher chance of visibility as I doubt I’m the only customer seeing this.

2 replies

dmatthews-rc
RevenueCat Staff
Forum|alt.badge.img+1
  • dmatthews-rc
  • RevenueCat Staff
  • September 3, 2026

Hi Eric,

Thanks for proactively informatively informing the community!

I was able to confirm the behavior your reported. I believe a recent change exacerbated a pre-existing race condition. I informed engineering, and they rolled back the recent change. The previous behavior should be restored.

If anyone notices this going forward, please let us know!

Cheers,
Debbie

Forum|alt.badge.img

Hi Eric,

Thanks for flagging this with the specific timestamp. What you are encountering is an eventual consistency / replication lag issue between RevenueCat’s internal event pipeline (which triggers the webhook) and the database replicas serving the /v1/subscribers/{app_user_id} REST API endpoint.

A few critical considerations and mitigations while the team investigates:

  • Webhook Payload as Source of Truth: Rather than immediately hitting /v1/subscribers upon receiving an INITIAL_PURCHASE event, rely directly on the event.entitlement_ids or event.entitlement_id array provided in the webhook payload itself. The webhook payload represents the exact state at emission time and eliminates the read-after-write race condition.

  • Exponential Backoff on Re-fetching: If your server architecture strictly requires synchronizing through /v1/subscribers, implement a short retry loop with exponential backoff (e.g., 500ms to 2s delay) when the subscriber endpoint returns an empty entitlement map right after an INITIAL_PURCHASE notification.

  • Google Play RTDN Batching: Google Play real-time developer notifications occasionally push state updates out of order during high-traffic windows, meaning subscriber record caches can take a couple of seconds to settle.

For more helpful updates and technical resources, visit.

Terms & ConditionsAccessibility statement