Context:
I'm currently using my own backend as the source of truth for subscription status. This is necessary since we have users who don’t go through the standard payment flow.
While debugging an issue, I noticed the following behavior in the Customer History (see attached screenshot, customerId: user_01jtg9rmtwe6x8g96v43bcn2z3):
-
A
trial started
event forpulso_suscripcion:pulso-anual
occurred at 2025-05-05 01:29 PM UTC. -
However, the first time this webhook was delivered to my API was at 2025-05-05 07:49 PM UTC.
-
This 6+ hour delay was the first attempt at delivery (not a retry), which likely caused a bug in my system logic (the user was able to subscribe again, so an expiration event then revoked its entitlement from my backend).
Another point: I explicitly do not want Platform Server Notifications, as those were sending events tied to anonymous IDs. (https://community.revenuecat.com/sdks-51/after-purchase-new-alias-app-user-id-created-6098?tid=6098&fid=51, https://www.revenuecat.com/docs/platform-resources/server-notifications/apple-server-notifications#user-identity)
Any recommendations to help me mitigate this delay? Maybe relying on the RevenueCat SDK if the subscription status from my backend is null?
