Skip to main content
Webhooks de saída são como a Caratuva avisa seu ERP de cada mudança de estado de um payment intent — KYC do comprador aprovado, transferência confirmada, liquidado, falhou. Você cadastra uma URL e uma lista de eventos uma vez, depois verifica a assinatura HMAC em cada entrega.

Inscrever

Resposta (o campo secret é o único lugar onde o segredo de assinatura aparece):
Guarde secret imediatamente — a Caratuva o criptografa em repouso e não consegue retorná-lo de novo. Se perder, gire-o.

Tipos de evento

Dois namespaces paralelos:
  • payment_intent.* — disparam apenas para faturas criadas via POST /v1/payments. Inscreva-se nestes se você é integrador B2B. Não verá ruído de nenhuma atividade do painel.
  • invoice.* — disparam para toda fatura (tanto criada via API quanto via painel). Inscreva-se nestes apenas se você também opera o painel.
Lista completa de eventos payment_intent.*:

Formato de entrega

Endpoints precisam responder com status 2xx em até 10 segundos. Qualquer outra coisa é tratada como falha de entrega.

Verificação de assinatura

O header de assinatura é t=<unix_ts>,v1=<sha256_hex>. O payload assinado é ${t}.${rawBody} (os bytes brutos do body HTTP, não um objeto JSON re-serializado). Sempre verifique contra os bytes brutos — re-serializar muda whitespace e ordem de chaves e quebra o MAC.

Passos

  1. Faça parse de t e v1 do header X-Caratuva-Signature.
  2. Rejeite a requisição se |now - t| > 300 (janela de replay de 5 minutos).
  3. Compute expected = HMAC-SHA256(secret, "${t}.${rawBody}") e compare em hex contra v1 com comparador de tempo constante.
  4. Use X-Caratuva-Delivery-Id como chave de idempotência do seu lado — replays com o mesmo id devem ser no-op.

Exemplo Node.js

Exemplo Python

Retentativas e backoff

A Caratuva tenta entrega imediata, depois reentrega em qualquer não-2xx ou erro de transporte com backoff exponencial: Após a sétima tentativa, a entrega vira dead_letter e a Caratuva para de tentar. Use GET /v1/webhooks/:id/deliveries para inspecionar entregas falhas e reenviá-las manualmente se preciso.

Listar inscrições

Inspecionar entregas

Cada linha carrega attempt, status (pending | delivered | failed | dead_letter), o responseStatus upstream e o próximo nextAttemptAt. Na prática, os valores que você verá hoje são pending, delivered e dead_letter — uma linha permanece pending entre retentativas e vira dead_letter após a tentativa final; failed está reservado.

Girar o segredo

A resposta carrega o novo secret exatamente uma vez. A rotação é imediata e atômica — a API armazena apenas um segredo por inscrição, então o segredo antigo para de verificar já na próxima entrega e não há janela de sobreposição com segredo duplo. Implante o novo segredo no seu verificador primeiro (ou atomicamente junto com a chamada de rotação); quaisquer entregas em andamento ou reentregues são re-assinadas com o novo segredo quando enviadas. Não configure seu verificador para aceitar “qualquer um” dos segredos esperando uma sobreposição — ela não existe.

Deletar (desativar)

Marca a inscrição como inativa (active=false). Nenhuma entrega futura dispara; as linhas históricas em deliveries continuam consultáveis.