Skip to main content
Toda resposta de erro da API da Cativa segue o mesmo formato, baseado no padrão RFC 7807 Problem Details. Isso vale para toda a API pública, servida em 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 adicional errors 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:
Use as chaves de 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.
Causa típica. Você enviou o request sem um campo obrigatório, ou com o body malformado. Corrija o payload antes de retentar. Retentar o mesmo request não vai mudar o resultado.
Causa típica. Faltou o header Authorization: Bearer cativa_live_..., a chave foi revogada ou o access_token OAuth expirou. Não entre num loop de retry. Gere uma credencial nova ou renove o token e refaça a chamada uma vez.
Causa típica. A credencial é válida, mas não tem permissão para essa operação (ex: uma chave sem o papel de admin tentando uma operação administrativa). Confira se você está usando a base URL certa e uma credencial com o escopo adequado.
Causa típica. O 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.
Causa típica. O request está bem formado, mas fere uma regra de negócio (atribuir um badge que o usuário já tem, matricular em curso encerrado, entre outros). Leia o detail, ajuste o estado e só então retente.
A resposta inclui o header Retry-After com o número de segundos a esperar. Veja Limites de taxa para o padrão de retry.
Causa típica. Algo falhou dentro da Cativa. Retente com backoff exponencial. Se o erro persistir, abra um ticket com o 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 responde 429 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 receber 429, 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.
Nunca faça retry cego em 4xx que não seja 429. Um 400, 401, 403, 404 ou 422 não muda de resultado se você repetir o mesmo request. Retentar só faz sentido para 429 e para a faixa 5xx.

Antipattern: ignorar o traceId nos logs

Sempre logue o traceId junto de qualquer erro da API que você capturar. Sem ele, o time de suporte da Cativa não consegue investigar seu caso. É como pedir ajuda sem dizer qual erro aconteceu. Inclua traceId, código HTTP e type no seu logger desde o primeiro dia.

Como reportar um erro

Ao abrir um ticket em dev@cativa.digital, inclua sempre:
  1. O traceId retornado no corpo da resposta de erro.
  2. O type e o status do erro.
  3. Um exemplo do request (URL, método, headers relevantes, sem expor a chave por inteiro).
  4. Horário aproximado, com fuso, em que o erro aconteceu.
Esses dados permitem ao time correlacionar com os logs internos rapidamente.

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.