Pular para o conteúdo principal

Envelope e erros

Toda resposta vem embrulhada​

Nenhuma rota devolve o recurso na raiz do corpo. O recurso vem sempre em data:

{
"code": 200,
"message": "OK",
"timestamp": 1758585600000,
"data": { }
}

Em respostas paginadas há também meta. Ao escrever seu cliente, leia response.data.data — não response.data.

O code repete o status HTTP da resposta, mas só no envelope de sucesso. O schema publicado em /openapi/v1.json não declara esse campo nas respostas — só data, message e timestamp — então um cliente gerado direto do spec pode sair sem code no tipo, e é preciso adicioná-lo à mão.

Respostas de erro usam um envelope diferente, sem code nenhum — ver a seção seguinte. Um cliente que leia err.response.data.code esperando o status recebe undefined em todo caminho de erro, a mesma armadilha já citada acima para response.data.

Erro de validação​

Campo inválido ou ausente responde 400 com uma entrada por campo, e as mensagens vêm em português. O envelope de erro não é o mesmo de sucesso: o status HTTP vem em status, não em code, e cada item de errors carrega também o valor rejeitado em value:

{
"success": false,
"status": 400,
"message": "Validation error",
"errors": [
{
"property": "ownerData",
"message": ["Deve ser um objeto"],
"value": null
}
],
"context": null,
"extraData": {}
}

O property usa caminho com ponto para campo aninhado (ownerData.cpf) e colchete para item de lista (rules[0].inputName). context e extraData normalmente vêm vazios (null / {}); quando a rota anexa contexto extra ao erro, ele aparece ali.

Erro de regra de negócio​

Vem com o status HTTP correspondente e uma mensagem em português, por exemplo 400 com "Tipo de documento não suportado".

Códigos​

códigoquando acontece
400campo inválido, ou regra de negócio recusou a requisição
401x-api-key ausente, malformada, revogada ou inválida
403recurso não disponível para a sua chave; em chave escopada, também rota sem a permissão necessária ou recurso fora dos projetos da chave
404o recurso não existe