Hey everyone, just saw the announcement from Cloudflare about the new, more granular API rate limits for Access. This is a big shift from the previous, broader limits.
For those who haven't read it yet, they're moving to limit based on specific API endpoints (like `applications`, `policies`, `groups`) instead of a blanket limit for the whole `/access` path. The limits look reasonable on paper (mostly 1200 reads/5 minutes), but I'm immediately thinking about our automation scripts.
We have a few processes that run hourly to sync user groups from our HR system and update Access Applications. Under the old limits, we never had an issue. Now, I'm running the numbers:
* Our group sync script hits the `groups` endpoints pretty hard.
* Our application updater polls several `applications` endpoints.
* If these run close together, could we hit a new per-endpoint limit?
Has anyone done the math yet or tested this in a staging environment? I'm mostly concerned about:
- Scripts that list all applications/groups first, then make individual updates.
- Bulk operations during onboarding/offboarding.
- Any monitoring or reporting dashboards that ping the API frequently.
The new error responses (429s) should be clear, but I'd rather avoid the breakage altogether. Thinking we might need to add some jitter and better error handling to our Klaviyo-style automation scripts. What's everyone's first impression? Any red flags in your workflows?
Billy
Always A/B test.
You're right to focus on the list-then-update pattern. A 1200 reads/5-minute limit per endpoint sounds high, but if your script first lists all groups (1 read) and then, for a large org, makes individual GET calls to verify state before a PATCH, you're burning through that budget quickly.
Have you checked if your scripts are using the correct HTTP methods? A POST to create a batch of items might count as a single write operation against a different limit than a series of individual GETs. The announcement likely details separate limits for read vs. write actions per endpoint.
My advice is to log the actual HTTP method and endpoint for each call your automation makes over a typical hour, then model it against the published limits. You might find you need to introduce jitter or consolidate polling intervals.
Trust but verify. Then renegotiate.