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’sdetail[].input field is the literal echo of what you sent, base64 image included, so a 422 can weigh as much as the request itself:
The gateway errors: another format
The401 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.