Rate limits, quotas, what every error code means and how your client should react to each one. Written for the engineer who has to make the integration survive a Monday morning backlog.
Talk to our technical team → — for integration questions, a security review or a volume estimate.
Three separate limits govern a key. They fail differently on purpose, because the right client reaction to each one is different.
429 with limit_per_minute. Retry with exponential back-off — this one clears on its own within the minute.429 with a quota object giving limit, used and remaining. Do not retry. Alert instead: the ceiling does not move until the period rolls or someone raises it.402. Do not retry. This is a commercial state, not a capacity one — it clears when the renewal is recorded, and retrying will not bring it forward.403 naming the scopes you do have. Never retry. This is a configuration error and will fail identically forever.4xx as retryable will hammer us for an hour over a 403 that was
never going to succeed, and will still be doing it when your on-call gets paged. Branch on
the error field, which is stable, rather than on the status code alone.Quota state comes back on every successful call, so your client can see a ceiling approaching rather than discovering it.
unlimited.X-Redacted-Count, X-Extracted-Fields, X-Signals-Found.200 is not proof of masking. If no number
could be read, the original document is returned unchanged and
X-Masked-Count is 0. Treat zero as a failure that needs review.
A pipeline that branches only on the status code will file unmasked documents and report
success while doing it — and nothing charges for a call that produced nothing, so
your billing will not flag it either.Processing is OCR-bound, so the honest answer depends on your documents rather than on a number we would like to print here.
429 with rate_limited, and only on that one. Jitter the delay so a fleet of workers does not retry in lockstep.X-Masked-Count: 0 to human review.manifest.json inside the ZIP; the HTTP status only tells you the batch was accepted.X-Quota-Remaining and raise a ticket at a threshold you choose, well before it reaches zero.402 as an operational alert to a human, not as a transient fault. It means somebody needs to renew.Availability commitments are agreed contractually on enterprise plans, with remedies. We do not publish a percentage on this page because we would rather commit to a number in a contract we have sized than advertise one.
It depends which 429. If the error field is rate_limited, back off exponentially with jitter and retry — it clears within the minute. If it is quota_exceeded, do not retry: the ceiling will not move until the period rolls or somebody raises it, so alert a human instead.
The plan's paid period has ended and has not been renewed. It is a commercial state rather than a capacity one, so retrying will not help. It clears when the renewal is recorded.
Not today. Every endpoint is synchronous: you send a document and the result comes back on the same call. For volume, the batch endpoints take many documents per request and return a ZIP with a per-document manifest. If asynchronous callbacks would change your architecture, tell us — it is a roadmap question and customer demand decides it.
There is a trial key with a small quota that calls the live service, so what you test is what you will run. There is no separate mock environment, deliberately: a sandbox that returns canned responses tells you nothing about how your documents actually OCR.
Not as installable packages. We publish worked client code for Python, Node.js and Java — retries, error branching and batching included — because a single REST endpoint taking a multipart upload does not need a dependency, and an unmaintained SDK is worse than none.
Tell us how many documents a month you process and what your peak looks like. We will size a plan, provision a key with a test quota, and answer a security questionnaire if you need one.