- Webhook Permanente: configurado no painel, com eventos assinados, retry automático e log de entregas
- Postback por Transação: URL específica no campo
postbackUrlao criar uma venda
Os dois convivem e são independentes. Se você configurar ambos, receberá as
duas notificações — com formatos e cabeçalhos diferentes.
Diferenças entre Webhook e Postback
Webhook Permanente
- Configurado no painel
- Você escolhe quais eventos quer receber
- Assinado com HMAC-SHA256 (
X-Nixfy-Signature) - Retry automático e reenvio manual
- Cobre vendas, saques e carrinho abandonado
Postback por Transação
- Configurado no campo
postbackUrlda venda - Recebe notificação apenas da transação específica
- Inclui
externalTransactionId - Com assinatura HMAC no header
X-Signature
Webhook Permanente
Você cadastra uma URL no painel e escolhe quais eventos quer receber. Quando o fato acontece, a Nixfy faz umPOST nessa URL com o payload em JSON e
cabeçalhos que permitem validar a origem.
Eventos disponíveis
O nome do evento viaja no cabeçalhoX-Nixfy-Event-Type — é por essa string
que seu servidor decide o que fazer.
Os eventos de carrinho não são ativados automaticamente, nem mesmo em
webhooks antigos que recebiam tudo. Marque-os no painel se quiser recebê-los —
a ideia é não mandar tráfego que seu servidor não espera.
Cabeçalhos de toda entrega
Validando a assinatura
A assinatura é calculada sobre o timestamp mais o corpo:- Recalcular o HMAC sobre
timestamp.corpo, usando os bytes brutos - Comparar em tempo constante (
timingSafeEqual,hash_equals) - Rejeitar timestamp fora da janela de 5 minutos — sem isso, uma requisição capturada valeria para sempre
- Deduplicar pelo
X-Nixfy-Event-Id - Responder
2xxrápido e processar depois
O segredo é exclusivo de cada webhook e exibido uma única vez, no
momento da criação. Ele não é recuperável por nenhuma leitura da API. Se
perder, crie outro webhook.
Retry e idempotência
O
X-Nixfy-Event-Id é estável por fato: sale.paid da venda 42 tem
sempre o mesmo id, em qualquer tentativa ou reenvio. “Venda pendente” e “venda
paga” da mesma venda são fatos diferentes, com ids diferentes.
Log de entregas e reenvio
Toda tentativa fica registrada e visível em Integrações → Entregas: evento, payload enviado, status HTTP devolvido, número de tentativas e erro. O botão Reenviar manda o mesmo payload e o mesmoeventId — você
recebe o fato que aconteceu, não o estado atual da venda. A assinatura é
recalculada com timestamp novo, porque a original já estaria fora da janela, e a
entrega vem com X-Nixfy-Redelivery: true.
Configuração
Configure no painel, em Integrações → Webhooks. A mesma gestão está disponível na API, autenticada pela sessão do painel:URLs apontando para IP privado ou loopback são recusadas em produção.
Formato da Notificação
O webhook permanente envia um payload com os seguintes campos:Campos do Webhook Permanente
integer
required
ID numérico da transação (Sale ID), mantido para integrações antigas
string
required
Identificador público da transação (UUID). O mesmo
sale.uuid devolvido na criação — use-o para casar a notificação com a vendainteger
required
ID do usuário (vendedor)
string
required
Valor da transação em centavos (formato string)
string
required
Data de criação da transação (ISO 8601)
string
required
Status atual da transação. Valores possíveis:
PENDENTE, EM_PROCESSAMENTO, PAGO, CANCELADO, RECUSADO, ESTORNADO, FALHA, CHARGEBACK, MEDstring
required
Método de pagamento. Valores possíveis:
PIX, CREDIT_CARD, DEBIT_CARD, BOLETOstring
Documento do cliente (CPF ou CNPJ)
string
Email do cliente
string
Nome completo do cliente
string
Telefone do cliente (apenas dígitos)
string
Chave PIX gerada (apenas para pagamentos PIX)
string
Código do boleto (apenas para pagamentos via boleto)
string
Informações de entrega em formato JSON string (apenas para produtos físicos).
null para produtos digitais.number
required
Taxa cobrada na transação em centavos. Apenas no webhook permanente.
array
required
Lista de itens da transação
integer
required
ID do item
integer
required
ID numérico da venda (mesmo que
id)string
required
Identificador público da venda (mesmo que
uuid)string
required
Título do produto
string
required
Preço unitário em centavos (formato string)
integer
required
Quantidade do item
boolean
required
Se o item é físico (
true) ou digital (false)integer
required
ID da transação (mesmo que
id). Apenas no webhook permanente.string
required
Tipo da notificação. Sempre
"TRANSACTION" para webhooks de transações. Apenas no webhook permanente.Postback por Transação
Postbacks são URLs específicas configuradas no campopostbackUrl ao criar uma venda. Recebem notificações apenas daquela transação específica.
Configuração
Configure o postback incluindo o campopostbackUrl ao criar a transação:
Segurança
Postbacks incluem assinatura HMAC-SHA256 no headerX-Signature para validação de segurança. A assinatura é gerada usando a chave secreta POSTBACK_SECRET_KEY configurada no ambiente do Nixfy Gateway.
Como funciona a assinatura:
- O Nixfy Gateway gera uma assinatura HMAC-SHA256 do payload JSON usando a chave secreta
POSTBACK_SECRET_KEY - A assinatura é enviada no header HTTP
X-Signature - Você deve validar a assinatura comparando com a assinatura esperada gerada localmente
Sobre a chave secreta: A chave
POSTBACK_SECRET_KEY é configurada no ambiente do Nixfy Gateway. Esta é a mesma chave que você deve usar para validar as assinaturas dos postbacks. Entre em contato com o suporte técnico para obter ou configurar sua chave secreta de postback.Nota importante: O JSON do payload é stringificado sem ordenação de chaves (JSON.stringify padrão). Não use sort_keys=True no Python ou qualquer ordenação de chaves, pois isso resultará em assinaturas diferentes e a validação falhará.Formato da Notificação
O postback por transação envia um payload com os seguintes campos:Campos do Postback por Transação
integer
required
ID numérico da transação (Sale ID), mantido para integrações antigas
string
required
Identificador público da transação (UUID), o mesmo
sale.uuid devolvido na criaçãointeger
required
ID do usuário (vendedor)
string
required
Valor da transação em centavos (formato string)
string
required
Data de criação da transação (ISO 8601)
string
required
Status atual da transação. Valores possíveis:
PENDENTE, EM_PROCESSAMENTO, PAGO, CANCELADO, RECUSADO, ESTORNADO, FALHA, CHARGEBACK, MEDstring
required
Método de pagamento. Valores possíveis:
PIX, CREDIT_CARD, DEBIT_CARD, BOLETOstring
Documento do cliente (CPF ou CNPJ)
string
Email do cliente
string
Nome completo do cliente
string
Telefone do cliente (apenas dígitos)
string
Chave PIX gerada (apenas para pagamentos PIX)
string
Código do boleto (apenas para pagamentos via boleto)
string
Informações de entrega em formato JSON string (apenas para produtos físicos).
null para produtos digitais.array
required
Lista de itens da transação. Cada item traz
saleId e saleUuid da vendastring
required
ID da transação no gateway de pagamento externo (adquirente). Apenas no postback por transação.
Comparação dos Formatos
Quando as Notificações São Enviadas
As notificações são enviadas quando a transação muda para um status final:PAGO- Pagamento confirmadoCANCELADO- Transação canceladaRECUSADO- Pagamento recusadoESTORNADO- Valor estornadoFALHA- Falha no processamentoCHARGEBACK- Chargeback identificado (cartão)MED- Mediação PIX iniciada
PENDENTE e EM_PROCESSAMENTO não geram notificações.
PIX Automático (assinaturas)
Cobranças recorrentes usam o mesmo webhook de qualquer outra transação — não há endpoint nem formato separado. O que muda é opaymentMethod, que vem como
PIX_AUTOMATICO.
Cada ciclo é uma transação nova, com seu próprio
id. Se um cliente
assina em janeiro e você cobra mensalmente, em março você já recebeu três
notificações independentes — não uma atualização da mesma transação.A autorização não gera notificação
Vale entender a diferença entre autorizar e cobrar:
Nas jornadas 1 e 2 a resposta da criação já avisa: vem com
sale: null. Você só
recebe a primeira notificação quando o débito acontecer, a partir da
dataInicial que você definiu.
Correlacionando os ciclos
Para ligar uma notificação à assinatura que a originou, use oidRec — o
identificador da recorrência devolvido na criação. Ele acompanha as vendas de
todos os ciclos daquele mandato, junto do contrato que você definiu.
Exemplo de Implementação
Node.js/Express
Python/Flask
Boas Práticas
Dica: Para testar webhooks localmente, use ferramentas como ngrok ou localtunnel para expor seu servidor local.

