Integration rate limits

Show support why an integration job is waiting

Delayed work needs an understandable reason and next action. Expose the relevant budget state without asking operators to inspect credentials or retry blindly.

In this article

Describe the waiting states

Separate waiting for provider capacity, waiting for local fairness, revoked access, invalid input and unknown outcome. These states need different responses.

Show the operation's next eligible time and the owner of unresolved work. Keep the original acceptance time visible so users' delay is not hidden by repeated rescheduling.

Avoid a single retrying label that can mean either normal backoff or a permanent loop.

Link to current provider policy

Document the relevant authentication scope, endpoint limits and response signals with a source review owner. Provider rules can change, so the runbook should identify where the current contract is checked.

Keep local scheduling choices separate from provider requirements. Operators should know whether a delay comes from an external limit or an internal priority policy.

Do not expose tokens or another customer's detailed usage in the support view.

Define safe interventions

Explain who can pause a scope, change a priority or resume exhausted work. Preserve attempt history and operation identity during those actions.

A force retry should not bypass the provider's timing or the mutation's reconciliation requirements. Record the reason for manual intervention.

Include the action when the shared scheduler itself is unavailable or its state appears inconsistent.

For a useful support display, show something like: accepted at 09:10, provider capacity available after 09:14, three attempts used, next action scheduled. Keep the time zone visible. This lets an operator distinguish normal waiting from a scheduler that failed to claim an eligible job.

If the next eligible time has passed with no attempt, investigate worker admission and shared state. If it is still in the future, another manual retry is unlikely to help. The display should lead to the appropriate diagnosis rather than merely expose a counter.

Rehearse a scoped throttle

Have the receiving team investigate one synthetic throttled account while another continues processing. Ask them to identify the next eligible time, current backlog and appropriate response.

Then present an unknown mutation outcome and confirm they use reconciliation rather than treating it as ordinary waiting.

The handover is complete when support can explain delay, preserve fair progress and recover the right class of failure without increasing rejected traffic or duplicating business work.

Primary sources

GitHub: REST API rate limits

References checked 11 September 2026.