Skip to main content

The codes, at a glance

The 400 messages

Error bodies look like this:
The uuid in an error body is generated on the spot and does not correspond to any transaction — it is not usable as relatedUuid and support cannot look it up.

The 422 echoes your whole request — image included

The validation error’s detail[].input field is the literal echo of what you sent, base64 image included, so a 422 can weigh as much as the request itself:
Never log raw error bodies. A logged 422 persists the document photo of a real person in your logs. Log the code, the message and the field path — never input.

The gateway errors: another format

The 401 and 404 come from the gateway, with statusCode instead of code:
A 401 with a key that “always worked” is usually an environment mix-up: the UAT key against the production URL or vice versa. Verify the URL + key pair before escalating.

The 500s

One 500 is deterministic and yours: sending relatedUuid in /front. It reproduces identically on every attempt — do not retry it; remove the field. Any other 500 is transient: retry with backoff, maximum 2 attempts. The determinism test is the same as always: if the retry returns the identical error, the cause is your request. healthCheck can return 408 while still answering "Service OK" on /version — treat it as a degradation warning, not an outage. A 503 means the OCR engine is down: nothing to fix on your side; retry later.

If you have to open a ticket

Write to customer.support@vusecurity.com with:
Data protection: never attach document photos or raw response bodies to a ticket unless support explicitly asks for them through a secure channel.

Back to the introduction

The decision rule, the three identifiers and the endpoint map of ID Analysis.
Last modified on September 9, 2026