Skip to main content
Toda notificação enviada pela Spedy é assinada. A assinatura permite confirmar que o POST recebido partiu da Spedy e que o corpo não foi alterado no caminho — sem ela, qualquer pessoa que descubra a URL do seu endpoint consegue enviar um evento forjado. A assinatura segue o padrão aberto Standard Webhooks, o que permite usar bibliotecas prontas em vez de implementar a verificação do zero.
Verificar a assinatura é opcional. O corpo das notificações não mudou e integrações criadas antes deste recurso continuam funcionando sem alteração.

Os headers da assinatura

Cada entrega inclui três headers:
O header pode trazer mais de uma assinatura durante uma janela de rotação (veja Rotacionar o segredo). Considere a entrega válida quando qualquer uma delas conferir.

Obter o segredo da conta

O segredo é da conta — o mesmo valor assina as entregas de todos os webhooks configurados, de todas as empresas.
cURL
O segredo pode ser consultado quantas vezes for necessário — não é revelado uma única vez. Se você o perdeu, consulte-o novamente; não é preciso rotacionar.
createdAt e previousSecretExpiresAt são devolvidos em UTC, com offset explícito (+00:00). Os demais campos de data da API usam o horário de São Paulo. Considere o offset ao calcular o fim de uma janela de rotação.

Como verificar

O conteúdo assinado é a concatenação do identificador da entrega, do timestamp e do corpo exatamente como recebido, separados por ponto:
Sobre esse conteúdo aplica-se HMAC com SHA-256, usando como chave os bytes resultantes da decodificação em base64 do segredo sem o prefixo whsec_. O resultado é codificado em base64 e comparado com cada entrada v1, do header.
Use o corpo cru da requisição, byte a byte. Desserializar o JSON e serializá-lo de novo altera espaçamento e ordem de campos, e a assinatura deixa de conferir. Na maioria dos frameworks isso significa ler o corpo antes de qualquer middleware de parsing.

Com uma biblioteca

O site do Standard Webhooks mantém bibliotecas oficiais para várias linguagens. Elas recebem o segredo, os headers e o corpo cru, e cuidam da verificação e da tolerância de tempo.

Sem biblioteca

Compare as assinaturas com uma função de tempo constante — timingSafeEqual em Node.js, hmac.compare_digest em Python, hash_equals em PHP. Comparação com == ou != vaza informação pelo tempo de execução.

Tolerância de tempo e retentativas

O webhook-timestamp permite rejeitar entregas antigas reenviadas por terceiros. A tolerância recomendada é de 5 minutos. Uma entrega que falha é reenviada com backoff crescente, e cada retentativa é assinada de novo, com timestamp do momento do reenvio. Uma retentativa que chega 16 horas depois passa normalmente na tolerância de 5 minutos. O webhook-id, por outro lado, permanece o mesmo em todas as tentativas — é por ele que se deduplica.

Rotacionar o segredo

Rotacione o segredo quando suspeitar de exposição ou por política interna. A troca gera um segredo novo e mantém o anterior válido por um período de transição:
cURL
Durante a janela, cada entrega vai assinada com os dois segredos — o novo e o anterior — no mesmo header webhook-signature. Isso permite atualizar o segredo no seu sistema quando for conveniente, sem perder entregas. Encerrada a janela, apenas o segredo novo é usado. overlapHours: 0 invalida o segredo anterior imediatamente. Use essa opção quando o segredo tiver sido exposto e a interrupção de entregas for aceitável até você atualizar o seu lado.
Uma nova rotação dentro de uma janela ainda aberta descarta o segredo mais antigo: a cada momento valem no máximo dois segredos.

Gerenciamento de webhooks

Crie, edite, desabilite e reative webhooks via API. Política de retry.

Eventos e payload

Tipos de evento disponíveis e o formato completo do payload.