https://apis.cativalab.digital/tenant/api/v2. Aprender esse formato uma vez significa tratar erros de qualquer endpoint da mesma maneira.
Esta página cobre três coisas: o shape do erro, o catálogo de códigos com um exemplo real de cada um, e o contrato de limite de taxa (429 com Retry-After).
As respostas JSON aqui são ilustrativas para você entender o formato. O schema autoritativo de cada endpoint (campos exatos, tipos, códigos possíveis) fica na aba API Reference.
Por que um formato único de erro
Sem um padrão, cada endpoint inventaria o próprio jeito de reportar falha, e o seu código precisaria de um parser diferente para cada rota. Com RFC 7807, você escreve um tratador de erro que lê os mesmos campos (type, status, title, detail, traceId) para qualquer resposta com status 4xx ou 5xx.
Formato padrão de erro
Erros de validação por campo
Em respostas de validação, um campo adicionalerrors pode vir populado com erros por campo, no formato Dictionary<string, ProblemDetailsFieldError[]>. Cada chave é o nome do campo do request e o valor é a lista de problemas daquele campo:
errors para destacar o campo problemático no seu formulário, e o code de cada item para mapear a mensagem traduzida que você mostra ao usuário. Nunca dependa do message em inglês para lógica.
Catálogo de códigos HTTP
Um exemplo de cada código
Abra cada código para ver um erro concreto e a causa típica.400 Validation Error (campo obrigatório ausente)
400 Validation Error (campo obrigatório ausente)
403 Forbidden (sem permissão para o recurso)
403 Forbidden (sem permissão para o recurso)
404 Not Found (recurso inexistente)
404 Not Found (recurso inexistente)
id na URL não existe nesse tenant, ou o recurso foi removido. Confirme o identificador. Lembre que IDs são únicos por tenant, então um id de outra comunidade retorna 404 aqui.422 Unprocessable Entity (regra de domínio violada)
422 Unprocessable Entity (regra de domínio violada)
detail, ajuste o estado e só então retente.429 Too Many Requests (limite de taxa)
429 Too Many Requests (limite de taxa)
Retry-After com o número de segundos a esperar. Veja Limites de taxa para o padrão de retry.500 Internal Server Error (falha do lado da Cativa)
500 Internal Server Error (falha do lado da Cativa)
traceId para o time correlacionar com os logs internos.Limites de taxa
A API da Cativa segue o contrato padrão de limite de taxa: quando você excede o permitido, ela responde429 Too Many Requests com um header Retry-After indicando quantos segundos esperar antes de tentar de novo.
Hoje o limite de taxa ainda não é imposto por chave na v1. Na prática, você dificilmente vai receber
429 em uso normal. Mesmo assim, escreva seu cliente para respeitar 429 e Retry-After desde já: o contrato é estável e o enforcement pode ser ligado sem aviso de mudança de API. Não fixe números de limite no seu código, apenas obedeça ao Retry-After que vier na resposta.Tratando 429 com Retry-After e backoff exponencial
A regra de ouro: ao receber429, espere o que o Retry-After mandar. Se ele não vier, caia num backoff exponencial com jitter. O mesmo padrão serve para 500, 502, 503 e 504.
Antipattern: ignorar o traceId nos logs
Como reportar um erro
Ao abrir um ticket em dev@cativa.digital, inclua sempre:- O
traceIdretornado no corpo da resposta de erro. - O
typee ostatusdo erro. - Um exemplo do request (URL, método, headers relevantes, sem expor a chave por inteiro).
- Horário aproximado, com fuso, em que o erro aconteceu.
Próximos passos
Identidade e usuários
Onde você verá
400 Validation Error de campo inválido com mais frequência.Webhooks
Como o
X-Cativa-Execution-Id ajuda a deduplicar webhooks reentregues, e a mesma curva de retry aplicada ao contrário.Primeira chamada de API
Faça o primeiro request autenticado e veja uma resposta de sucesso antes de tratar erros.
API Reference
O schema autoritativo de cada endpoint, com os códigos de erro possíveis por rota.
