The problem in plain language
An API-driven workflow succeeds most of the time, then begins rejecting requests during busy periods, batch jobs, campaign spikes or concurrent processing. Individual applications can remain online while orders, customer updates, documents, payments or operational records arrive late or fail to move.
Because the failure is intermittent, it is easy to misread. The integration passed testing, it works on a quiet Tuesday, and the vendor's status page shows no incident. Then month-end, a marketing send or a bulk import arrives and a portion of the business transactions simply do not complete. By the time anyone investigates, traffic has dropped and everything appears healthy again.
What the buyer is actually trying to solve
The buyer is not merely searching for “an API error”. They are trying to make a cross-system process reliable when one participating service controls how much traffic it will accept within a period. The search language is usually symptom-first: “429 too many requests”, “integration fails at peak times”, “sync works sometimes”, “API throttling errors”, or “records missing after bulk update”. Each describes the same underlying condition: demand on a shared interface has exceeded what the workflow was designed to handle.
Evidence and system mechanism
IETF RFC 6585 defines HTTP 429 Too Many Requests specifically for rate limiting: the client has sent too many requests in a given amount of time. It notes that a response can include details of the condition and a header indicating how long the client should wait before trying again. HTTP semantics in RFC 9110 define Retry-After as the mechanism for telling a client how long it ought to wait before a follow-up request. The operational implication is straightforward: rate limiting is a normal interface condition that clients and integration workflows need to handle deliberately rather than treating every rejection as an unexpected outage.
Microsoft's Azure Architecture Center describes the consequence of ignoring this. Its Rate Limiting pattern explains that performing large numbers of operations against a throttled service can increase traffic and reduce throughput, because rejected requests have to be tracked and retried, and a throttling limit may force multiple passes of resending data. The recommended response is to control the rate at which the application sends requests—for example by placing work on a durable message queue and processing it at a rate within the service's limits.
A business failure becomes likely when request bursts, concurrency or retry behaviour exceed the available limit and the integration has no controlled queue, pacing, retry policy, idempotency protection or observable exception path.
How intermittent failure actually happens
Several mechanisms combine to make rate-limit failures appear random:
- Retry storms. When a request is rejected and immediately retried, the retry adds load at exactly the moment the provider is asking for less. Many clients retrying together can keep a quota exhausted long after the original burst has passed.
- Shared quotas. Limits often apply per account, application or key rather than per workflow. A new reporting job or automation can consume headroom that a customer-facing process relied on, without either team knowing the other exists.
- Bursty business events. Average traffic may be well within limits while a single event—an import, a campaign, a scheduled sync—sends thousands of calls in minutes.
- Unsafe retries. Microsoft's Retry pattern guidance warns that if an operation is not idempotent, retries can cause it to execute more than once—for instance when a service processed a request successfully but failed to send the response. In business terms, that can mean a duplicate order, invoice or message.
- Silent abandonment. Some tools retry a fixed number of times and then drop the record, logging a technical error that nobody reviews.
Illustrative example. A hypothetical retailer synchronises orders from its e-commerce platform to its fulfilment system every few minutes. On a normal day each run sends a few dozen calls. During a promotion, a run attempts several thousand. The fulfilment API begins returning 429 responses; the connector retries immediately, three times, and then marks the remaining orders as failed in a log. Most orders arrive, some arrive hours later after a manual rerun, and a few are only discovered when customers ask where their parcels are.
Problem owner and why now
Integration, application and platform owners usually carry the technical responsibility, while the business process owner carries the consequence. Urgency rises when transaction volumes increase, new automations create more API calls, a vendor changes limits, or several workflows begin competing for the same quota. Seasonal peaks, migrations and bulk data clean-ups are common triggers because they produce exactly the bursts that ordinary testing never exercises.
Warning signs
- Failures cluster around scheduled jobs, campaigns, month-end or imports.
- “Rerunning it fixed it” is the usual resolution.
- Logs show 429 or throttling responses that nobody is alerted on.
- Duplicates appear in downstream systems after busy periods.
- Nobody can say which workflows share a given API key or quota.
Economic consequence
The cost can appear as delayed fulfilment, manual re-entry, customer-service investigation, reconciliation work, missed process deadlines or support effort. Intermittent failures are often more expensive than clean outages because they are harder to detect and harder to diagnose: each one prompts an investigation that ends with “it seems fine now”. The right measurement is process-specific: count rejected or deferred requests, affected business transactions, recovery effort and the time between the original event and successful completion.
Root cause
The root cause is often not “the API is unreliable”. It is a capacity contract that the consuming workflow has not incorporated into its design. Common contributors include uncontrolled parallelism, immediate retries, several consumers sharing one quota, large batch bursts and no distinction between transient rate-limit responses and permanent failures. Ownership is a further contributor: when no one is responsible for the integration as a whole, nobody tracks how close it runs to its limits.
Practical intervention
- Map the provider limits and identify which workflows share them.
- Measure request patterns by business event rather than only average API traffic.
- Introduce controlled queuing, pacing and backoff where appropriate.
- Respect explicit retry guidance when the provider supplies it.
- Make retried operations safe against duplicate business actions.
- Monitor both technical responses and eventual business completion.
- Escalate quota or architecture changes when legitimate peak demand exceeds the available service envelope.
Retry design deserves particular care; Mellorca covers it in how to design retries without creating duplicate work. Completion monitoring matters equally, because a technically successful integration can still leave business transactions unfinished—see why integration monitoring misses business completion.
Trade-offs
Queuing and pacing make throughput predictable but add latency: a record may wait minutes rather than failing instantly. For some processes that is acceptable; for others, such as payment authorisation or live customer interactions, it is not, and the answer may be prioritisation, a higher quota or a different integration pattern. Buying more quota is sometimes the right decision, but it postpones rather than removes the design issue if traffic is uncontrolled. And every queue needs an owner, because a queue nobody watches simply relocates the failure. Messages that fail and sit unread are their own problem—see why failed integration messages sit unnoticed.
Diagnostic questions
- Which business processes depend on APIs with documented or observed rate limits?
- What happens to a transaction after a 429 response?
- Can several workflows consume the same quota?
- Are retries paced, observable and safe against duplicates?
- Can operations identify which business transactions are still waiting?
- Has anyone tested the integration at realistic peak volume rather than average volume?
What good looks like
Rate limits are treated as part of the integration contract. Traffic is shaped intentionally, transient failures have controlled recovery paths, duplicates are prevented, and operators can trace a business event from first request through eventual completion. Peak events are planned for in advance, quota consumption is visible, and a named owner decides when demand justifies a change in architecture or commercial terms.
Where Mellorca fits
Mellorca can map API-dependent workflows, assess integration capacity and failure paths, design queues and retry controls, improve transaction observability and help establish ownership for business-critical integrations through Systems Implementation & Integration.
Method note
This article establishes the failure mechanism from HTTP standards and published architecture guidance and applies it to business integration design. The example is illustrative, not a client case. Actual limits, retry requirements and quota behaviour are provider-specific and must be verified against the API being used.
Sources and further reading
- https://www.rfc-editor.org/rfc/rfc6585.html#section-4 (last verified 10 October 2026)
- RFC 9110: HTTP Semantics (last verified 10 October 2026)
- Rate Limiting Pattern - Azure Architecture Center (last verified 10 October 2026)
- Retry pattern - Azure Architecture Center (last verified 10 October 2026)