Integration rate limits
Review the retry budget across every layer
A bounded loop is not enough when several layers retry independently. Count the maximum downstream attempts and keep one policy responsible for the operation.
In this article
Trace the retry stack
Inspect the application, SDK, HTTP client, queue and caller. Record which failures each layer retries and how it counts attempts.
A job runner may retry a function that already exhausted its own HTTP retries. The resulting downstream count can be much larger than the number shown in the job record.
Use a controlled failure to observe actual requests rather than relying only on configuration names.
Check timing and termination
Verify provider timing hints, exponential delay or other local policy and any jitter. Define the maximum elapsed time or attempt count for the business operation.
Make sure a timeout at one layer does not leave another layer continuing unnoticed after the caller believes work stopped.
Persist delayed eligibility where work must survive process restarts. A retry budget should not reset to zero every time a worker crashes.
Preserve mutation safety
Check that retries retain the intended request identity and payload where the provider's idempotency mechanism requires it. Do not rebuild a changed request under an old key.
Classify unknown outcomes separately from confirmed throttling or validation rejection. A later attempt can repeat an effect even when its scheduling policy is correct.
Keep exhausted operations visible with the evidence needed for reconciliation.
Test the shared scope
Run multiple workers against one synthetic provider budget and verify aggregate admission. Then throttle one account and confirm other eligible scopes continue.
Inspect slot recovery after a worker dies and behaviour when the shared limiter is unavailable. The failure policy should be deliberate rather than silently reverting to unlimited calls.
Approve the retry design when its total attempts, timing, identity and shared coordination can be demonstrated. A helper named retryWithBackoff does not establish those guarantees by itself.
Primary sources
GitHub: REST API rate limitsReferences checked 11 September 2026.