A valid signature still needs a trust decision
An Oprindo sample had a matching asset hash and a valid signature, alongside an untrusted credential result. The useful story is in those separate answers.
Integrations7 min read
How a bulk import shares an API limit
A worked 120-call budget shows what an import costs interactive work, why retries consume the same capacity and how completion promises change with the scheduling rule.
The import and the person share a door
The API is healthy, but a colleague’s single product correction is waiting behind an import with thousands of calls left to send. Both use the same provider allowance. More import workers will not make that allowance larger; they will give the correction more company in the queue. The choice is how to share the available calls while the import runs, and how much longer the import should take in return.
Handling a 429 usually starts with waiting and retrying. The more interesting decision happened earlier, when the scheduler admitted work and chose who would wait. A bulk job can receive priority simply because it arrived first, even if no one intended ordinary staff corrections to stop behind it. Put that choice into the design before treating rate limiting solely as a response parser and a recovery loop.
Consider an illustrative product-catalogue import of 1,500 records. Each needs three external calls, for 4,500 calls in total. Assume a smooth, paced budget of 120 calls per minute, with no free burst capacity, negligible service time for this calculation and all required data available. These are assigned planning assumptions, not a real provider's quota or a measured integration. They let us separate the arithmetic of sending work from the operational complications around it.
If the import uses all 120 calls per minute, its idealised sending time is 37.5 minutes. Reserve 30 for interactive requests and it has 90 left, making the sending time 50 minutes. That extra twelve and a half minutes is the visible cost of protecting ordinary staff work. Calling the faster option better without naming that trade would make the scheduler's accidental priority the business policy.
Account for every claimant on the allowance
The budget belongs to the scope the provider defines: it might be an account, application, user, resource or some combination. MDN's 429 guidance describes that implementations vary.[1] A separate API key should not be assumed to create a separate allowance. Find the actual scope before giving each worker its own optimistic counter.
A local counter sees only callers that pass through it. Another integration, an administrator’s bulk action or a separate endpoint limit can still produce 429s. Watch the provider responses and leave room for demand this scheduler cannot see. The configured budget is the application’s sending plan; the response tells you what the service is currently permitting. Giving each worker a neat local counter will not make the uncounted traffic disappear.
Track calls per completed business record, including lookup, pagination and retries. A job labelled synchronise 1,500 products can become more expensive if it repeatedly fetches the same reference table. Caching permitted stable data can reduce demand, while a supported batch endpoint may change it further. Check the batch's partial-success contract before assuming it can be replayed as one operation.
Keep capacity and concurrency separate. Capacity in our example is calls per minute; concurrency is how many operations are active together. More concurrency can help use an available allowance when calls are slow. Once the sending budget is full, adding workers mainly creates more contenders. If a downstream service is struggling, those contenders can also spend more time holding connections and waiting, which makes a seemingly simple speed improvement a different operating problem.
Retries are customers of the same budget
Now allow fifteen calls per minute for retry traffic while retaining thirty for interactive work. The bulk lane receives seventy-five. Its 4,500 calls then require at least sixty minutes of sending time under the stated steady assumptions. The figure shows that allocation against the 120-call ceiling. Retries have not become free because their purpose is recovery rather than new business work.
Suppose interactive demand stays at sixty calls per minute. Giving it priority leaves sixty for the import before retries, and the sending lower bound becomes seventy-five minutes. That may be exactly the compromise the business wants. It has to travel with the finish estimate, though: the import cannot keep its old completion promise after the same calls have been assigned to live work. A different fairness rule would make a different promise possible.
Retries can multiply across layers too. Suppose a job layer, an application wrapper and an SDK each allow two attempts, and every path keeps failing. The deepest operation can be called up to 2×2×2, or eight times, for one top-level request. The exact behaviour depends on the stack; the calculation shows why retry ownership should be explicit. Inspect SDK defaults before adding another recovery loop around them.
Amazon's retry guidance describes the additional load retries can place on an overloaded dependency and the role of backoff and jitter in avoiding synchronised bursts.[3] These mechanisms redistribute attempts over time without adding service capacity. The scheduler still needs bounded retries and, where side effects matter, the original business-operation identity. Delaying an unsafe repeat does not change which external action it may duplicate.
Retries and interactive work leave 75 calls per minute for the import
Illustrative steady allocation:1,500 records ×3 calls =4,500 bulk calls. With 75 bulk slots per minute, idealised sending time is 4,500÷75=60 minutes, before extra service delay.
Budget: 120 calls per minute
- Interactive updates30 calls per minute
Reserved capacity protects live work instead of putting every correction behind the import.
- Retry traffic15 calls per minute
Recovery still consumes the same paced sending budget.
- Bulk import75 calls per minute
The remaining allowance sets the idealised 60-minute sending lower bound.
A waiting request needs a scheduled time
HTTP 429 may include Retry-After. The header can express a delay in seconds or an HTTP date, so treating every value as an integer is an incomplete parser.[2] Use the provider's documented response handling, including what to do if the header is missing or malformed. A retry system needs a bounded fallback policy rather than an immediate loop or an indefinite wait invented by accident.
Persist the next eligible attempt with the work item. A worker should release the job until that time instead of occupying an execution slot in a tight sleep-and-retry cycle. When many items share a retry boundary, appropriate jitter can spread their return, subject to the minimum wait the provider requested. The scheduler still applies the shared budget when those items become eligible again.
Show why an item is waiting. Provider capacity, missing data and exhausted attempts call for different decisions, even if each appears as a paused row. Keep the original business age, next eligible attempt and effect on the finish window visible. If an operator presses Retry, schedule or escalate it through the same allowance. A manual button that jumps around the policy would make the displayed plan a description of only some of the traffic.
Do not use an exact completion countdown unless the available evidence supports it. A rate-based lower bound is useful for planning, but network time, changing demand and unavailable records can extend the job. Report the remaining population and the observed processing rate alongside assumptions. A person deciding whether to wait until lunch or postpone another task needs a realistic interval more than a precise-looking prediction that silently excludes recovery.
Layered retries can multiply one request
An illustrative failing stack in which each of three layers allows two attempts.
Follow the labelled arrows. On a narrow screen, scroll sideways if needed.
Decide what should happen when both lanes stay busy
There is a fairness question the arithmetic cannot answer for you. Strict interactive priority can protect staff work while leaving a large import waiting indefinitely if interactive demand consumes everything. Strict first-in-first-out processing can finish the import while making small corrections intolerably slow. A reserved share, permitted borrowing when a lane is idle and an escalation for old bulk work are possible policies, each with consequences.
Write the chosen rule in business terms before selecting a queue library. For example: keep thirty calls per minute available to interactive updates; let the import borrow unused capacity; return borrowed capacity when live work appears; alert when the oldest import record approaches its agreed window. Then implement the rule at the actual shared scope and retain evidence of how calls were assigned. The wording makes the intended compromise reviewable.
Use a representative safe trial containing both the import and interactive requests. Pause and resume the import, introduce a bounded 429 response sequence and inspect the next-attempt timestamps. The question is whether the policy behaves as described, not whether the test can make the provider reject enough traffic. Record actual observations separately from the illustrative estimates in this article.
The calculation might lead the team to buy a larger tier, remove repeated lookups or negotiate a later finish. Those are different repairs, and the shared budget helps explain which constraint each addresses. Before promising when the 1,500-record import will finish, decide what remains available to a colleague making a correction and to the retries that will follow failures. The estimate should describe that operating choice, including the work it deliberately lets go first.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotReferences & further reading
Primary sources behind this article. Living documentation may change.
- MDN:429Too Many Requests
- MDN: Retry-After
- Marc Brooker: Timeouts, retries, and backoff with jitter Published 5 December 2019
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A few more things
worth a read.
Back to the reading room 
Should this old instruction still run?
Repairing a consumer makes replay possible. Current state, dependencies and recovery admission decide whether it is still appropriate.
The backfill arrived after the live update
Historical work needs a population boundary, revision policy and crash-safe checkpoint strategy before its final page can mean done.