GET /api/v2/get. Você cadastra um endpoint, escolhe os
eventos que interessam e a Escrybe faz um POST com um payload JSON nele.
Os endpoints são gerenciados no painel em Configurações → Webhooks
(/opcoes/webhooks), onde você também vê cada tentativa de entrega, a resposta
que seu servidor deu e pode reenviar uma que falhou.
Eventos
Envelope
Toda entrega tem o mesmo formato no nível de cima:data é aditivo: campos novos podem aparecer com o tempo. Leia os campos que
você usa e ignore o resto, em vez de validar contra um schema fechado.Ambiente
environment diz qual ambiente da Escrybe produziu o evento:
O mesmo valor vai no header
X-Webhook-Environment, então dá para desviar ou
descartar um evento antes de fazer o parse do corpo.
Headers
Verificando a assinatura
Quando você define um segredo, cada entrega é assinada com HMAC-SHA256 sobre o corpo bruto da requisição. Compare com uma função de tempo constante e leia o corpo antes de qualquer parse de JSON ou middleware que o reescreva.Entrega e retentativas
- Seu endpoint precisa responder 2xx em até 30 segundos.
- Uma entrega que falha é tentada de novo até 3 vezes, com backoff exponencial: 5, 10 e 20 minutos.
- Após 3 falhas consecutivas em eventos reais o endpoint é pausado automaticamente e você recebe um e-mail. Reative no painel.
- O corpo da resposta é armazenado (até 10.000 caracteres) para você ver o que seu servidor respondeu.
- Entregas de teste nunca são repetidas e nunca contam para a pausa.
A entrega é at-least-once. Uma retentativa pode chegar depois do seu servidor
já ter processado o evento — por exemplo quando ele respondeu com atraso. Use
o
delivery_id como chave, ou faça o handler idempotente por id do pedido e
status.Payloads
order.created
Pedidos de carta, telegrama e e-Carta:type: "email" e um data diferente:
order.status_updated
type: "email" o corpo traz opened e date_opened no lugar de
tracking e files.
Status de carta, telegrama e e-Carta:
Status de e-mail registrado:
tracking.updated
event_detail_type é new_tracking_code quando o código é atribuído pela
primeira vez e new_tracking_record quando os Correios registram novos eventos.
tracking_records é o objeto dos Correios como eles devolvem, do evento mais
novo para o mais antigo. status_delivery é vazio, delivered,
going_back_to_sender ou delivered_to_sender.
rr.created
rr_type é rr para o AR físico digitalizado e rr_electronic para o que os
Correios devolvem digitalmente. file vem null quando o documento não pôde
ser lido.
Este payload embute o documento inteiro em base64 e é bem maior que os outros.
Garanta que seu endpoint aceita um corpo de alguns megabytes.
webhook.test
Testando no homolog
homolog.escrybe.com.br é uma cópia completa da plataforma, com banco e
credenciais próprios. Os pedidos de lá permitem exercitar todos os eventos sem
postar nada de verdade: na página de pedidos você move o pedido pelos status na
mão e adiciona eventos de rastreio, e cada ação dispara o mesmo webhook que a
produção dispararia, marcado com environment: "homolog".
E-mail registrado e WhatsApp são entregues de verdade a partir do homolog, então
os destinatários precisam estar cadastrados em Whitelist de homologação
(
/homolog-whitelist). Quem não estiver na lista tem o envio recusado e o
pedido fica com status de falha, explicando o motivo.