Skip to main content

Envelope (típico)

{
  "error": "descrição",
  "status": 400
}
TODO: chaves adicionais (código, correlation_id) se existirem na implementação — a origem mostra o mínimo.

Códigos HTTP (mapa geral)

CódigoSignificadoAção
200Sucesso em leitura / confirmação de webhook de entrada (parceiro)Siga a operação.
201Criação de recursoGuarde o id e externalId.
400Validação de payloadCorrija o corpo.
401AutenticaçãoConferir Bearer e validade/escopo do token.
404Não encontradoConferir parâmetros, ambiente e o UUID usado.
409Conflito (ex.: externalId duplicado)Outro externalId ou recuperar o recurso existente.
422Regra de negócioAjuste valor, prazo ou pré-condições.
500Erro internoRetentativas (com cuidado).
Tabela de troubleshooting: Códigos e sintomas.

Retentativas

  • 5xx ou timeout em leitura (GET) ou leitura semelhante: use backoff exponencial com teto, sem martelar a API.
  • 4xx (fora de rate limit) em escrita: não retente sem corrigir o payload.
TODO: rate limit (429, Retry-After) — a origem não cita; confirmar com a implementação do gateway.

Divergência entre webhook e GET /.../{id}

  1. Trate o webhook como at-least-once; valide a assinatura e deduplique.
  2. Se a consulta mostrar o estado “à frente” do último evento processado, use o estado idempotente e reconcile logs.
  3. Em PROVIDER_RESULT_UNKNOWN ou RECONCILIATION_REQUIRED, use o guia de reconciliação operacional.

Falhas do seu endpoint de notificação

  • Após validar a assinatura, responda 2xx rapidamente. Erros 5xx do seu lado alimentam retentativas com backoff (fila, conforme a origem).
  • Handlers devem ser idempotentes.

Dados pessoais (LGPD)

O documento de origem cita: documentos podem ser mascarados em respostas de detalhe. Evite registrar dados sensíveis indevidamente.

Ver também