Skip to main content
Este documento descreve os payloads de webhook relacionados a resgates de recompensas. Os tópicos Reward_Redeemed (30) e Reward_Cancelled (31) acompanham o ciclo de vida de um resgate. No painel, eles aparecem como Recompensa resgatada e Recompensa cancelada. Os dois compartilham a mesma estrutura base, e o cancelamento acrescenta os campos do cancelamento. Use estes tópicos para sincronizar resgates com sua integração. Eles são independentes de Communication_RedeemPoints e Communication_RewardCustomRedeemNotification, que continuam seguindo as regras de comunicação e só são enviados quando a comunicação de resgate é disparada.

Resgate de recompensa

O tópico Reward_Redeemed (30) é enviado quando o cliente troca pontos por uma recompensa.

Quando o evento é gerado

O evento é gerado em todos os resgates, para qualquer tipo de recompensa (cupom, cashback ou recompensa customizada) e qualquer origem: página do programa, widget, checkout, API e PDV. A origem vem no campo RedeemOrigin. Cada resgate gera no máximo um evento por assinatura. O evento é enviado mesmo que o resgate já tenha sido cancelado quando a entrega acontece; nesse caso, o cancelamento chega separadamente em Reward_Cancelled.
No checkout, cada atualização do carrinho pode cancelar o resgate anterior e criar um novo. Nesses casos, você recebe um Reward_Redeemed para cada resgate e um Reward_Cancelled para cada resgate substituído. Use RewardId para cruzar os dois eventos.

Exemplo

Exemplo completo com o envelope padrão, em um resgate de cashback feito no checkout:

Campos do payload


Recompensa cancelada

O tópico Reward_Cancelled (31) é enviado quando um resgate de recompensa é cancelado e os pontos voltam para o cliente.

Quando o evento é gerado

O evento é gerado nos cancelamentos feitos pelo fluxo padrão de cancelamento de resgates, incluindo:
  • cancelamento pela API e pelo PDV;
  • remoção do resgate pelo cliente no checkout;
  • cancelamentos automáticos do checkout: atualização do carrinho, carrinho abandonado e chave de segurança ausente ou inválida;
  • cancelamento automático do resgate quando o pedido que o utilizou é cancelado.
A origem de cada cancelamento vem no campo CancellationType. Um resgate só pode ser cancelado uma vez, então cada resgate gera no máximo um evento de cancelamento por assinatura.
Os cancelamentos automáticos do checkout são frequentes: a cada atualização do carrinho, o resgate anterior pode ser cancelado e substituído por um novo. Use CancellationType para filtrar as origens relevantes para sua integração.

Exemplo

Payload do cancelamento do resgate do exemplo anterior, feito pela API (sem o envelope, que segue o mesmo formato com Topic 31 e TopicName "Reward_Cancelled"):

Campos do payload

Todos os campos de Reward_Redeemed, com estas diferenças:

Enums

Indica o tipo da recompensa resgatada.

Entrega

Apenas assinaturas ativas com o tópico selecionado no momento do evento recebem a notificação. Ativar a assinatura ou adicionar o tópico não recupera resgates ou cancelamentos anteriores. Rotinas internas de correção que usam o fluxo padrão de resgate e cancelamento também geram estes eventos, em geral com CancellationType null. Ajustes feitos diretamente no resgate, sem passar por esse fluxo (algumas sincronizações específicas de plataforma ou correções no banco), não geram eventos.
As entregas são assíncronas, podem levar alguns minutos e podem se repetir.
  1. Use o Uuid do envelope para deduplicar as tentativas da mesma entrega. Ele permanece igual nas retentativas; assinaturas diferentes têm seus próprios Uuid.
  2. Use TopicName + RewardId como chave de idempotência de negócio: cada resgate gera no máximo um evento de cada tópico por assinatura. Use RewardId para cruzar Reward_Redeemed com Reward_Cancelled e PointId para cruzar com os tópicos de pontos.
  3. Não há garantia de ordem entre os tópicos. No checkout, quando o resgate é cancelado logo depois de feito, o Reward_Cancelled pode chegar antes do Reward_Redeemed do mesmo resgate. Trate o cancelamento como estado final: se o Reward_Redeemed chegar depois, não reative o resgate.
Os dados do payload são lidos no momento do envio. Customer e PointsBalance podem refletir movimentações de pontos posteriores ao evento, principalmente em retentativas. Em algumas plataformas, rotinas de reconciliação também podem ajustar CashValue e Points do resgate depois do evento.

Formato das datas

RedeemDate, CancelledDate e o Timestamp do envelope estão em UTC, mas são enviados sem designador de fuso e com até seis casas decimais nos segundos, por exemplo 2026-10-05T14:05:00.127941. Trate esses valores como UTC: em JavaScript, por exemplo, new Date("2026-10-05T14:05:00.127941") interpreta a data como hora local. Estes tópicos usam a política de entrega existente, com os headers, método, URL e corpo configurados na assinatura.
Prefira o envelope padrão para ter acesso ao Uuid. Um corpo personalizado recebe os campos deste payload, como RewardId e Customer.Id, mas não recebe automaticamente os campos do envelope. Consulte a configuração do corpo personalizado.

Tópicos Disponíveis


Documentação atualizada em Outubro de 2026.