# 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.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## 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.

### A shared scheduler controls provider work

Queued operations are grouped by the relevant provider scope. Admission and retry timing follow both available budget and local priority.

1. **Pending operations**: Preserve identity, account and business priority
2. **Shared admission**: Check the relevant rate and concurrency budgets
3. **Provider request**: Observe outcome and documented limit signals
4. **Next action**: Complete, 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.

## Sources

- [GitHub: REST API rate limits](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api)
- [IETF: HTTP 429](https://datatracker.ietf.org/doc/html/rfc6585)