An integration can work perfectly in a small demonstration and struggle when the business imports a large file or several staff act at once. External APIs often limit request rates or concurrent work. Those limits are part of the integration's operating environment. Plan how work waits, retries and becomes visible to staff instead of treating every temporary limit as an unexplained failure.
Identify the workload that creates the burst
Imagine a Tamworth wholesaler updating a catalogue in its sales and warehouse systems. A batch change may create many API requests at the same time that staff are creating urgent orders. List the actions that generate calls and identify which can be grouped, cached or paced. Read the provider's current contract rather than assuming one universal rate. Stripe's documentation, for example, distinguishes types of rate and concurrency limits. Other providers expose different limits and signals, so the implementation should respond to the service it actually uses.
Queue work with a business priority
A background catalogue refresh may be able to wait while a new order needs prompt attention. Put queued work into understandable categories and avoid allowing a large low-priority batch to block every interactive action. Show staff that work is waiting and when the last successful update occurred. Do not invent a precise completion time unless the system can estimate it usefully. Give an operator a way to pause or cancel an unnecessary batch, with clear consequences for items already completed and those still waiting.
Retry according to the response
Some services indicate when a request may be retried. MDN documents the Retry-After response header, which can express a delay or a date. Follow the provider's documented retry behaviour, use appropriate backoff and avoid all waiting requests restarting together. A retry also needs to be safe for the business action: repeating a read differs from repeating a create operation. Set a limit or escalation point for repeated failures. Otherwise an integration can quietly keep attempting work that requires a corrected credential, changed data or human review.
Test with constrained throughput
Run a controlled batch under deliberately limited processing capacity and observe both the queue and the staff experience. Include an urgent action while the batch is active. Before release, confirm:
- The provider limits and retry signals are understood.
- Work is paced and important actions have an agreed priority.
- Waiting, completed and failed items are visible.
- Cancellation, safe retries and exhausted attempts have explicit outcomes.