Skip to main content
Gateways de pagamento tem o hábito ruim de reenviar o mesmo webhook várias vezes (retries por timeout, tentativas de “garantia”). Se a xTracky simplesmente processasse todos, você teria Purchase duplicado no painel da Meta — e ROAS inflado artificialmente. A xTracky bloqueia isso em duas camadas.

​
Camada 1 — Dedup por LeadId + orderId (V2)

Na integração V2, cada evento é identificado por:
Ao chegar um POST na /api/integrations/api, a xTracky verifica se já processou esse par nas últimas horas. Se sim, retorna 200 OK mas não dispara nada.
Você pode reenviar à vontade — retries do seu backend, replays de fila, testes manuais. Só o primeiro conta.

​
Camada 2 — Hash SHA-256 do payload (V1)

Na integração V1 (webhooks legados de gateways), a xTracky gera um hash SHA-256 do payload inteiro do webhook e compara com hashes recentes:
Mesmo dedup: se o hash bate, o evento é descartado.

​
O que conta como “mesma venda”?

Duplicata — descartado.
Processado. Isso pode acontecer se o mesmo pedido for reportado por dois caminhos (webhook + API manual), ou se você reutilizou o orderId pra outra venda (o que você não deveria fazer).
Processado. É um cliente comprando duas vezes — deve mesmo virar dois Purchase.
A dedup cai no hash do payload. Se o payload inteiro for byte-a-byte igual → dedup. Se mudar um único caractere (timestamp, ID de transação, etc.), passa.

​
Janela de dedup

A janela é curta (horas, não dias). Se você reprocessar um webhook antigo semanas depois, ele vai passar de novo — o que raramente é o comportamento desejado.
Se você faz replay em massa de webhooks antigos (por exemplo, restaurando um backup), abra um ticket com a gente antes: podemos flaggar o replay como não-produtivo pra evitar poluir os painéis de anúncio.