Skip to main content

Os códigos, de relance

As mensagens de 400

Os corpos de erro se parecem com isto:
O uuid de um corpo de erro é gerado na hora e não corresponde a nenhuma transação — não serve como relatedUuid e o suporte não consegue consultá-lo.

O 422 ecoa a sua solicitação inteira — imagem incluída

O campo detail[].input do erro de validação é o eco literal do que você enviou, imagem base64 incluída, então um 422 pode pesar tanto quanto a solicitação:
Nunca registre corpos de erro crus. Um 422 logado persiste a foto do documento de uma pessoa real nos seus logs. Registre o código, a mensagem e o caminho do campo — nunca input.

Os erros do gateway: outro formato

O 401 e o 404 vêm do gateway, com statusCode em vez de code:
Um 401 com uma chave que «sempre funcionou» costuma ser mistura de ambientes: a chave de homologação contra a URL de produção ou vice-versa. Verifique o par URL + chave antes de escalar.

Os 500

Um 500 é determinístico e seu: enviar relatedUuid em /front. Ele se reproduz idêntico a cada tentativa — não repita; remova o campo. Qualquer outro 500 é transitório: repita com backoff, no máximo 2 vezes. O teste de determinismo é o de sempre: se a repetição devolve o erro idêntico, a causa é a sua solicitação. O healthCheck pode devolver 408 enquanto /version ainda responde "Service OK" — trate como um aviso de degradação, não como indisponibilidade. Um 503 significa que o motor de OCR está fora do ar: nada a corrigir do seu lado; repita mais tarde.

Se precisar abrir um chamado

Escreva para customer.support@vusecurity.com com:
Proteção de dados: nunca anexe fotos de documentos nem corpos de resposta crus a um chamado, a menos que o suporte peça explicitamente por um canal seguro.

Voltar à introdução

A regra de decisão, os três identificadores e o mapa de endpoints do ID Analysis.
Última modificação em 9 de setembro de 2026