We implemented the suggested Webhook implementation.
From the docs: “To simplify the logic of handling different webhook types, we recommend creating a polling system using the GET /subscribers REST API to sync the subscription status of the customer from RevenueCat to your database. Then, each webhook event can simply be a trigger to call this sync function.”
We implemented this solution. However, with this suggested implementation we get a lot of 429 (Rate Limit) error:
We have a fallback that will retry the call to GET /subscribers, however I was wondering if there were other workarounds you can think of?
Are there plans to change this rate limit? I know other people have the same issue here
Best answer by kaitlinView original
I’m now seeing 500s when calling the Webhook (cropped the userId on purpose, I can send the full URLs privately)
Timestamps are in Paris time:
We’ll continue with the retry strategy. In the meantime, let us know if you plan any changes to make the calls to GET /Subscriber more available/reliable :)
You’re already implementing our typical suggestion of retrying. Another possibility I could mention, as this seems to be happening often, is to implement a one or two second wait for your GET /subscriber call after the webhook trigger.
Additionally, if your internal logic does not expose the secret key (prefixed with `sk_`) in the app, you could use this API key instead for a more lenient rate limit for high-volume scenarios.
Regarding your 500 errors - are you getting these in your sandbox or production environment?
The 500s where indeed in production. We’re also getting timeouts (after 30 seconds) from time to time, but nothing too crazy.
Thank you for the tip about the secret key, we’ll use this instead