Legal translation volume is bursty, not steady: nothing arrives for a week, then a data room drops four hundred documents at four on a Friday. That makes documents-per-hour the wrong evaluation metric — the number that matters is how long a burst of four hundred takes to drain, which is set by concurrency limits, whether a real batch endpoint exists, and how the API signals that you are pushing too hard. A vendor that returns
429 with Retry-After is easier to design against than one that quietly queues your work, because silent queueing hides the difference between slow and stuck.
This guide covers sizing a burst, finding the real limits, building backpressure that holds, and deciding what gets translated first when everything is urgent.
Legal Volume Arrives in Spikes
The demand curve for a corporate practice is not a curve. It is a flat line interrupted by events: a data room opens, a regulator issues a request with a deadline, a deal signs and every ancillary document needs a local-language version by Tuesday.
Average throughput describes none of that. A pipeline comfortably handling forty documents a day can fail completely on a four-hundred-document Friday, not because it is slow but because nothing in it is bounded, queued or prioritised. Everything is submitted at once, the vendor starts rejecting, a naive retry loop amplifies the rejections, and the whole burst lands on Monday in an unpredictable order.
So the design question is not "how fast is this API" but "what happens to my system when ten times normal volume arrives in one minute". Those are different questions, and only the second one gets asked in an incident review. Practitioners moving large multilingual volumes on a budget hit the same wall from the cost side: unbounded submission is expensive as well as fragile.
Time to Drain Is the Number Worth Asking For
Reduce the evaluation to one figure you can compute. For a burst of N documents, with a per-document latency L and an effective concurrency C, the drain time is roughly N × L / C, plus whatever the queue ahead of you contains.
That formula makes the questions specific. What is L for a document of the size you actually send — not a sample paragraph, a sixty-page agreement? What is C, and is it a limit on requests per second, on jobs in flight, or on pages being processed? Is C per API key, per account, or per organisation, because the answer decides whether spinning up a second key helps or does nothing?
Then ask the question vendors rarely volunteer: is C shared with other tenants at peak? A concurrency figure that holds at nine in the morning and halves during a busy afternoon will not show up in a quiet trial. Ask whether the limit is contractual or best-effort, and get the answer somewhere durable.
Documented Limits Versus Discovered Ones
Published rate limits are a starting hypothesis. The limits your integration actually meets are often different — lower during peaks, higher after an account tier change, and enforced at more than one layer.
Find them deliberately, in a controlled window, before a real matter does it for you. Ramp submissions from one concurrent job upward, holding each level long enough to see the steady behaviour, and watch three things: whether throughput stops rising, whether per-job latency starts climbing, and whether errors appear. Throughput plateauing while latency climbs means you found a queue. Errors appearing means you found a limit.
Record what you find with dates, because limits change silently. And check whether limits are enforced per endpoint: submission may be generous while status polling is strict, which produces the odd failure mode where your jobs are accepted fine but your reconciliation poller starts getting throttled at exactly the moment it has the most jobs to check.
Whether a Genuine Batch Endpoint Exists
There is a real difference between an API that accepts a batch and one that merely tolerates four hundred sequential calls. Ask directly, and ask what the batch abstraction gives you.
A useful batch endpoint accepts a manifest of files in one request, returns a batch ID with child job IDs, exposes per-file status rather than a single aggregate state, and lets you fetch completed outputs while siblings are still running. That last property matters more than it sounds: a batch that only releases results when every file is finished means one problematic scanned PDF holds three hundred and ninety-nine finished translations hostage.
Also establish the failure semantics. If a batch of four hundred contains three files that cannot be processed, does the batch fail, or does it complete with three failures recorded? Partial success is the behaviour you want and it needs to be visible per file. And confirm whether a batch is cancellable mid-flight, because "we submitted the wrong folder" is a normal event in data room work.
Explicit Rejection Beats Silent Queueing
When you exceed a limit, there are two possible vendor behaviours and they are not equivalent.
The good one is explicit rejection: HTTP 429, ideally with Retry-After, and a body distinguishing a short-term rate limit from a quota exhausted for the month. It is a signal. Your client can slow down, your queue can hold work, your dashboard can show that you are rate limited rather than broken.
The bad one is silent queueing. Requests are accepted, everything returns 202, and the work simply takes progressively longer. Nothing is wrong from the API's point of view and nothing is observable from yours. You cannot distinguish a busy vendor from a stuck one, you have no basis for backpressure because nothing pushed back, and your only signal is a job age metric climbing for reasons you cannot attribute.
Ask which behaviour you get, and verify it in the ramp test. If it is silent queueing, ask whether queue depth or estimated start time is exposed anywhere. Something is much better than nothing.
Backpressure Belongs in the Queue, Not the Retry Loop
The instinct on 429 is to retry. The correct response is to stop submitting for a while, which is a different thing and lives in a different place.
Put the burst in your own durable queue on arrival and let a bounded worker pool drain it. Concurrency is then a number you control, set just below the vendor's limit, adjustable without a deploy. Add a shared token bucket so all workers throttle together rather than each discovering the limit independently, and exponential backoff with jitter so a throttled fleet does not resynchronise into a thundering herd on the next attempt.
A circuit breaker completes it: after repeated rejections, stop submitting entirely for a cooling period and surface the state, rather than burning quota on requests you know will fail. Capacity management is an explicit control expectation under ISO/IEC 27001, and for financial-sector firms the operational resilience requirements in DORA make "we had no way to shed load" an uncomfortable finding.
Deciding What Goes First When Everything Is Urgent
Four hundred documents are not four hundred equal documents, and FIFO wastes the one property of a burst you can exploit.
Two lanes handle most of it. An interactive lane for documents someone is waiting on right now — a share purchase agreement a partner needs before a call — with reserved concurrency. A bulk lane for the rest of the data room, which needs to be done by Monday. Reserving even a small share of capacity for the interactive lane means a background dump can never block urgent work, which is the failure everyone remembers.
Within the bulk lane, order by something meaningful: risk-bearing documents before administrative ones, or shortest first if the goal is maximum documents reviewable tonight. Add ageing so nothing starves, and per-matter fairness so one enormous deal cannot monopolise the pipeline while three smaller ones wait. Prioritisation is cheap to build at queue level and impossible to retrofit into a loop that submits everything immediately.
Reviewer Capacity Is Part of Throughput
The pipeline does not end at the API. If translated documents feed human review, reviewers are usually the narrower pipe, and machine throughput that outruns them just relocates the queue.
Model both. Four hundred documents translated overnight and needing full review at ten minutes each is sixty-seven person-hours — a week for one reviewer. That arithmetic, not the API, determines when the work is actually finished, and it is the number to quote when someone asks for Monday.
The lever is review depth rather than review speed: triage so that documents carrying obligations get post-editing to an ISO 18587 standard while routine correspondence gets a spot check. Deciding that split in advance, per document type, is what makes a burst survivable, and it is the same judgement covered in choosing between automated and human review.
Load-Testing Before a Deal Does It For You
Half a day of deliberate load testing tells you more than any published limits page.
Ramp test. Increase concurrency stepwise until throughput plateaus. Record the level and what happened at it — rejection or stall.
Burst test. Submit a realistic burst of documents of realistic size, all at once, and measure drain time end to end, including retrieval and filing.
Sustained test. Hold the burst rate for an hour. Some limits are windowed and only appear after minutes.
Poison test. Include a handful of oversized, scanned and corrupt files, and confirm the batch completes with failures recorded rather than failing whole.
Cancel test. Cancel mid-batch and check what is billed and what state the children end in.
Run these on the plan and batch submission path you will use in production, and keep the numbers. They are what you compare against when someone reports it feels slower than it used to.
Sources and Further Reading
ISO/IEC 27001 — information security management, including capacity controls
Large-scale multilingual translations on a budget — practitioners describing what high-volume submission does to cost and turnaround
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the pipeline described here. We update these guides when the underlying standards, regulations or file formats change.
Size the burst, not the average — the Friday data room is the real test. Try BluTranslate free.