Rate Limit too low

Hi ​@enes-455812,

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

Most apps don’t call the API per user action. They lean on caching + the SDK + webhooks to reduce read/write pressure. A few practical patterns that work well are as follows:

Instead of checking credits on every tap, fetch once per session (or every N seconds) and cache in your backend (e.g., Redis) with a short TTL eg 120s. Use that cached balance to allow/deny token-based actions. Reconcile in the background on a cadence or when you receive relevant events from RevenueCat. Docs on Virtual Currency webhook events can be found here: https://www.revenuecat.com/docs/offerings/virtual-currency/events#webhook-events

When multiple actions would update the same user’s balance, queue them and coalesce within a tiny window (e.g., 2000 ms). Apply a single “net” update instead of many small ones.

For access-gating that can be modeled as entitlements/subscriptions, let the client SDK (iOS/Android etc.) read & cache status locally, and only use the API when you truly need a server-authoritative balance.

That said, if you still require a higher rate limit you can open a support ticket with us, and include the rate you’re targeting, we can review it and increase the rate limit for your project, id everything checks out.

Hope this helps, let me know if you have any other questions.

Best,

Hussain

Hey Hussain,

thank you very much for your help. Those are very good advises you gave me.
I’ll try to implement them, but I think I stick to the logic to build the Credit system in my backend, since this is the more scalable solution right now.