API rate-limit management: keep business integrations moving

Identify the limit you are actually hitting

Capture the response status, relevant limit headers, request identifier, endpoint and account context. Compare the timing with scheduled imports and background jobs. Avoid collecting access tokens or unnecessary record content in diagnostic logs. Check whether reads and writes share the same quota.

Microsoft Graph's throttling guidance explains that limits depend on the scenario and that responses can include a Retry-After value. Xero separately documents limits associated with connections and application traffic. These examples show why the relevant provider documentation should determine the scheduling model, not an assumed universal requests-per-second value.

Reduce requests before adding more concurrency

Look for polling that repeatedly retrieves unchanged records. Use supported change tracking, incremental filters, webhooks or bulk endpoints when they fit the task. Cache reference data only within its freshness and access requirements. A list of tax codes may need a different refresh policy from an order's current payment status.

Check pagination and the amount of data returned. Fetch the fields required by the workflow instead of transferring large objects that will be discarded. Before choosing a bulk endpoint, understand partial failures and the provider's maximum payload size; fewer HTTP calls do not automatically mean a reliable import.

• Use incremental cursors or timestamps with a documented overlap strategy.
• Avoid unnecessary reads immediately after every write.
• Separate interactive requests from large background jobs.

Queue work and retry with boundaries

Store pending operations durably with their account, priority and next eligible attempt time. Follow a documented Retry-After value where available; otherwise use an appropriate backoff policy with jitter and a maximum retry budget. Ensure an update can be retried without creating duplicate business effects.

Schedule fairly across tenants or organisations. A bulk synchronisation for one customer should not consume all worker capacity and block urgent work for others. Apply concurrency limits at the scope that matters, and reduce pressure when the provider signals that capacity is exhausted.

Make delayed work visible to users and operators

Show when a record was last synchronised and distinguish queued, failed and complete work. A user should not have to infer a stale payment status from the absence of an error message. Set alerts for queue age and prolonged throttling as well as individual failed requests.

After a backlog clears, reconcile expected and completed operations. Measure whether the integration can keep up with normal peak demand under its actual entitlement. If it cannot, redesign the schedule or discuss supported capacity options with the provider; bypassing controls or rotating identities to evade quotas is not a sound solution.