Integration rate limits
Rate limits belong in the integration scheduler
A retry delay inside one request does not coordinate a fleet of workers. Model the provider's shared limits and decide which work receives the available capacity.
In this article
Find the scope of the limit
An API may limit by application, account, user, endpoint or concurrent work. Several limits can apply at once. Ten workers each respecting a local request rate can still exceed a shared account budget.
Read the provider's current rules and response signals for the actual authentication method. GitHub, for example, documents primary and secondary limits with different dimensions. One global requests-per-minute constant cannot represent every API contract.
Keep provider policy separate from the application's own fairness and capacity choices. The local scheduler may intentionally use less than the maximum to preserve room for important work.
Share the decision across workers
Coordinate requests that consume the same budget through a suitable shared scheduler or atomic limiter. Track concurrency separately from time-window usage where the provider requires both.
A delayed job should release resources that unrelated work can use. Sleeping inside a worker while holding its only execution slot can stop progress for other accounts whose budgets remain available.
- Pending operationsPreserve identity, account and business priority
- Shared admissionCheck the relevant rate and concurrency budgets
- Provider requestObserve outcome and documented limit signals
- Next actionComplete, reschedule or hold without blind retries
Respect the response without inventing a guarantee
HTTP 429 indicates excessive request rate and may include Retry-After. The exact counting scope and recovery policy come from the provider. Other status codes can also carry provider-specific throttling meaning.
Parse supported retry timing correctly and keep a bounded fallback for missing or invalid hints under the integration policy. Do not immediately retry every rejected request in a tight loop.
Spread eligible retries where appropriate so all workers do not return at the same instant. The aim is to reduce renewed contention, not to bypass the provider's limit.
Keep retries tied to the operation
A throttled read may be straightforward to reschedule. A mutation with an unknown outcome needs its idempotency or reconciliation rules as well as a later time slot.
Set a total attempt or elapsed-time budget and make exhausted work visible. Nested retries in the HTTP client, SDK and job runner can multiply attempts unless one layer owns the policy.
Preserve fair progress
A large historical import should not consume every slot needed by current customer actions. Define priority and fairness by the business requirement, with safeguards against starving lower-priority work forever.
Measure completed operations, backlog age and throttling by scope. A dependable integration makes steady useful progress within the provider's rules, rather than treating repeated rate-limit responses as normal throughput.
Primary sources
GitHub: REST API rate limitsIETF: HTTP 429References checked 11 September 2026.