Skip to main content

The codes, at a glance

The 400s: a single error, with an index

The 400 body points at the offending image with imageNumber (0-based):
One bad image aborts the whole batch. If you send 4 images and the third has no face, you get a single 400 with imageNumber: 2 and no results — there are no partial results. If your flow tolerates per-image failures, send one request per image.

The 500s come as plain text

Two request errors do not return a tidy 400 but a 500 whose body is the literal string Internal Server Error — not JSON:
  1. Omitting the images field.
  2. Sending an operations list shorter than images.
Your HTTP client must not assume every response is JSON: wrap the parsing and treat a parse failure as an error, never as an approval. How to tell a transient 500 from one of yours: retry it once with backoff. If it comes back identical, it is deterministic — your request causes it; validate images and the operations alignment in your code and stop retrying.

The gateway errors: another format

The 401 and 404 are not emitted by the service but by the gateway, and their body has another format (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 422s: contract violations

A non-JSON body, a body that is not an object, or an info out of range (2–256 characters) return 422 with a per-field breakdown in detail. These are programming errors, not data errors: fix them in development, do not handle them in production.

Retry policy

If you have to open a ticket

Write to customer.support@vusecurity.com with:

Back to the introduction

The decision rule, the endpoints and the operation map of Face Analysis.
Last modified on September 9, 2026