# API rate-limit management: keep business integrations moving Published by Britixo | 2026-10-29 | CRM & integrations Canonical page: https://britixo.com/business-guides/api-rate-limit-management/ When an API throttles requests, reduce the demand and schedule work according to the provider's documented limits. Respect retry guidance, avoid immediate repeated calls and keep business operations in a durable queue. Review whether the integration is fetching unchanged data or making unnecessary requests. Different limits may apply by tenant, application, endpoint or time window, so one global delay is rarely a complete solution for a busy integration. ## When this guide is useful Teams whose integrations slow down, fail or produce incomplete updates under load. - HTTP 429 responses appear during imports or busy periods. - One customer account delays work for every other account. - A retry loop increases traffic when the provider is already throttling. - Full datasets are downloaded repeatedly to find a few changed records. ## 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. ## Prepare for a useful conversation - Provider limits recorded by endpoint, account and application scope. - Request metrics and a view of the main sources of traffic. - Efficient retrieval and freshness rules for cached data. - Durable queues with bounded retries and fair scheduling. - Queue-age alerts and a reconciliation check after backlogs. ## How Britixo can help Britixo can investigate throttling in an existing integration and design a more predictable processing model. Work can include request analysis, incremental synchronisation, queue scheduling, retry handling and user-visible status. We can also test the proposed workload against current provider entitlements and document where capacity or API limitations affect the design. The aim is reliable completion of business work, not simply more requests per second. Contact Britixo with the systems involved, approximate volumes and sanitised error examples so we can distinguish inefficient retrieval from a genuine capacity constraint. [Contact Britixo](https://britixo.com/contact/?enquiry_type=contact_consultation#contact-form) ## Common questions ### Will adding more workers solve API throttling? Often it makes the problem worse by increasing concurrent demand. First identify the limit and use scheduling that stays within the relevant provider boundary. ### Should we retry every HTTP 429 response? Retry eligible work according to provider guidance, with a bounded policy and durable state. Do not make immediate unlimited retries, and preserve safety for repeated writes. ### Are webhooks a complete replacement for polling? Not always. Webhooks can reduce repeated reads, but you may still need reconciliation and recovery for missed or delayed events. Use the provider's supported delivery model. ## Related guides - [Webhook failures and retries: keep integrations from losing or duplicating work](https://britixo.com/business-guides/webhook-failures-retries/) - [Connect CRM and accounting software without creating competing records](https://britixo.com/business-guides/connect-crm-accounting-software/) - [Control business AI costs with budgets, routing and useful measurements](https://britixo.com/business-guides/control-business-ai-costs/) ## Sources and further reading - [Microsoft: Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) - [Xero: API limits](https://developer.xero.com/faq/limits) Prepared with AI assistance and checked against linked primary documentation. [Editorial approach](https://britixo.com/business-guides/#editorial-approach). Product availability and delivery scope are confirmed for your requirements.