POST para uma URL que você cadastra.
Esta página explica como receber e validar os eventos. Para cadastrar, listar
e remover endpoints de webhook, veja Referência: Webhooks.
Para a lista de eventos disponíveis, veja Eventos.
Como funciona
1
Você cadastra um endpoint
Registre uma URL pública (
http ou https — recomendamos fortemente HTTPS) e,
opcionalmente, um secret. Você também escolhe quais eventos quer receber — uma lista
vazia significa “todos os eventos”. Veja Referência: Webhooks.2
Um evento acontece
Algo muda na sua conta (ex.: uma transação é paga). A Z2Pay seleciona seus webhooks
ativos que escutam aquele tipo de evento.
3
A Z2Pay faz POST no seu endpoint
Para cada webhook correspondente, a Z2Pay envia um
POST com o envelope JSON do
evento no corpo da requisição e cabeçalhos de identificação/assinatura.4
Seu servidor responde 2xx
Responda com um status
2xx em até 30 segundos. Qualquer outra coisa (resposta fora
da faixa 2xx, timeout, falha de conexão) conta como falha — e o Z2Pay reenvia
automaticamente com intervalos crescentes (veja
Entrega e retentativas).O envelope do evento
Todo webhook chega no mesmo formato de envelope. O conteúdo específico do recurso fica sempre dentro dedata.
string
Identificador único desta entrega (prefixo
whd_). Cada tentativa de entregar o mesmo
evento ao mesmo endpoint usa o mesmo id — use-o como chave de idempotência (veja abaixo).object
O objeto do recurso relacionado ao evento (a transação, o reembolso, a assinatura, etc.).
O formato de
data depende do type.string
Data e hora em que o evento ocorreu, em ISO 8601 com timezone (UTC). Não é o horário do
envio: retentativas e reenvios da mesma entrega preservam o valor original. Use-o para
ordenar eventos no seu lado — retentativas podem chegar fora de ordem (veja
Entrega e retentativas).
string
Identificador da sua company (prefixo
comp_).Cabeçalhos da requisição
TodoPOST de webhook inclui:
Os cabeçalhos
X-Webhook-Timestamp e X-Webhook-Signature só são enviados quando você
cadastrou um secret no webhook. Sem secret, não há assinatura para validar — por isso
recomendamos sempre configurar um secret.O
X-Webhook-Timestamp é informativo e não entra no cálculo da assinatura — a
assinatura cobre apenas o corpo da requisição. Não há proteção anti-replay baseada em tempo:
para se proteger contra o reenvio de uma requisição capturada, implemente deduplicação pelo
id do envelope (prefixo whd_), como descrito em
Idempotência no seu receptor.Verificando a assinatura
Quando o webhook temsecret, a Z2Pay calcula a assinatura assim:
rawBody é o corpo bruto da requisição — os bytes exatos do envelope JSON (com id,
type, data, occurredAt e companyId) que a Z2Pay enviou. Não faça parse e re-serialize
(JSON.stringify): assine os bytes recebidos, exatamente como chegaram (veja o aviso abaixo).
Exemplo em Node.js
Idempotência no seu receptor
O mesmo evento pode chegar mais de uma vez (por exemplo, quando você reenvia manualmente uma entrega que falhou, ou quando o mesmo fato gera um novo evento interno). O seu endpoint deve ser idempotente.1
Use o id da entrega como chave
Guarde o
id do envelope (prefixo whd_) ao processar o evento. Ele é estável entre
tentativas da mesma entrega.2
Ignore o que já foi processado
Antes de aplicar efeitos colaterais, verifique se aquele
id já foi processado. Se sim,
responda 2xx e não faça nada de novo.3
Responda rápido
Faça o trabalho pesado de forma assíncrona (fila/worker). Responda
2xx assim que validar
a assinatura e registrar o evento.O
X-Webhook-Event-Id identifica o evento de origem e também pode ser usado para correlação
e deduplicação. Já o id do envelope é específico da entrega ao seu endpoint.Do lado da Z2Pay existe uma deduplicação de despacho: o mesmo evento não gera duas entregas
para o mesmo webhook dentro de 1 hora. Ainda assim, mantenha a idempotência no seu receptor —
reenvios manuais entregam o mesmo envelope de novo (mesmo
id), e um evento reemitido depois
dessa janela chega como uma entrega nova.O que a Z2Pay espera da sua resposta
Tempo limite
Cada
POST tem um tempo limite de 30 segundos. Se o seu servidor não responder dentro
desse prazo, a tentativa conta como falha e entra no ciclo de retentativas.O que conta como sucesso
Apenas respostas HTTP na faixa 2xx contam como entrega bem-sucedida. Redirecionamentos
(
3xx) são seguidos, e o resultado é decidido pelo status final; 4xx e 5xx
contam como falha.Boas práticas
Sempre configure um secret
Sempre configure um secret
Sem
secret, não há cabeçalhos de assinatura e você não consegue garantir que a requisição
veio da Z2Pay. Configure um secret forte ao cadastrar o webhook em
Referência: Webhooks.Valide a assinatura antes de processar
Valide a assinatura antes de processar
Rejeite com
401 qualquer requisição cuja assinatura não bata. Não processe o evento antes
de validar.Processe de forma assíncrona
Processe de forma assíncrona
Enfileire o evento e responda
2xx rapidamente. Processamento inline que passa de 30s
vira timeout — e o Z2Pay vai retentar algo que você já processou. Por isso a
deduplicação pelo id (acima) não é opcional.Trate o evento como dica, não como verdade absoluta
Trate o evento como dica, não como verdade absoluta
Em fluxos críticos (ex.: liberar um pedido), confirme o estado consultando a
Referência: Transações com o
id recebido em data.Veja também
Entrega e retentativas
Retentativas automáticas, desativação automática e reconciliação.
Eventos
A lista de tipos de evento (
type) que a Z2Pay envia.Referência: Webhooks
Cadastrar, listar e remover endpoints de webhook.
Erros
Formato e códigos de erro da API.
Convenções
IDs com prefixo, valores em centavos e datas em ISO 8601.