Skip to main content
A Malga utiliza o serviço de webhooks para notificar o seu sistema sobre os eventos ocorridos no motor de assinaturas. Através de webhooks, você consegue atualizar seu sistema sempre que um evento importante acontece, como a criação de uma assinatura, mudança de status ou criação de cobranças automáticas.

Fluxo básico para receber notificações via webhooks

  • Crie um serviço com um endpoint acessível dentro do seu sistema para receber as requisições de notificação dos eventos de assinatura.
  • Registre seu endpoint na Malga criando um webhook para receber notificações dos eventos desejados.
  • A Malga enviará uma requisição HTTP para seu endpoint com os dados do objeto alterado sempre que o determinado evento registrado no seu webhook acontecer.

Criação de um webhook

Realize a criação e gestão de webhooks usando o Serviço de Webhooks.

Evento de notificação enviado

Quando um determinado evento ocorre no motor de assinaturas, a Malga cria um objeto do tipo event que é enviado através de uma requisição HTTP para o seu endpoint cadastrado. O evento é imutável dentro da estrutura de notificações da Malga, isso significa que os dados do objeto que sofreu alteração são gravados junto com o evento, representando o estado do objeto imediatamente após o evento que o alterou. Exemplo de requisição de notificação de evento de uma assinatura enviada pela Malga para seu endpoint:

Eventos suportados para notificação via webhooks

Exemplos de payloads

Estrutura padrão do payload

Todos os eventos de assinatura seguem a mesma estrutura base. A diferença está no campo event e nos dados específicos dentro de data.

Evento subscription.trial_started

O evento subscription.trial_started inclui informações sobre a assinatura que iniciou o processo de trial:

Evento subscription.activated

O evento subscription.activated inclui informações adicionais sobre a primeira fatura que foi processada com sucesso e vai para o status active:

Evento subscription.unpaid

O evento subscription.unpaid inclui informações adicionais com o histórico de cobranças da fatura que falhou na última tentativa e atualizou a assinatura para unpaid:

Evento subscription.expired

O evento subscription.expired avisa que a última fatura referente àquela assinatura já foi paga e ela foi para o status expired:

Evento subscription.canceled

O evento subscription.canceled é recebido quando uma assinatura é cancelada. Isso pode ocorrer de duas formas:
  1. Cancelamento manual: Via endpoint de cancelamento ou atualização da assinatura
  2. Cancelamento agendado efetivado: Quando o scheduler processa um cancelamento agendado e a data efetiva chega
Quando o cancelamento vem de um agendamento, os campos cancelAtPeriodEnd e scheduledCancellationReason estarão presentes no payload (se scheduledCancellationReason foi fornecido durante o agendamento). Exemplo de cancelamento manual:
Exemplo de cancelamento agendado efetivado:

Evento subscription.cancelation_scheduled

O evento subscription.cancelation_scheduled é enviado quando:
  • Um cancelamento agendado é criado pela primeira vez
  • A data de cancelamento agendado (scheduledCancellationAt) é atualizada

Evento subscription.cancelation_scheduled_removed

O evento subscription.cancelation_scheduled_removed é enviado quando o agendamento de cancelamento é removido (por exemplo, quando cancelAtPeriodEnd é definido como false).
Note que quando o agendamento é removido, os campos scheduledCancellationAt e scheduledCancellationReason não aparecem no payload (são removidos do objeto subscription).

Evento subscription.paused

O evento subscription.paused é recebido ao pausar uma assinatura:

Evento subscription.resumed

O evento subscription.resumed é recebido ao retomar uma assinatura que estava pausada:

Evento subscription.updated

O evento subscription.updated é recebido ao atualizar dados de uma assinatura:

Evento subscription.cycle_failed

Este evento é enviado quando o processamento de uma nova fatura de cobrança falha devido a alguma inconsistência nos dados da assinatura. Um exemplo comum é quando o merchant vinculado à assinatura foi desativado.
Nesses casos, nenhuma transação é criada.

Comportamento especial para startAt sendo hoje

Quando uma assinatura é criada com startAt definido como a data atual, o motor de assinaturas processa a primeira cobrança imediatamente.
Nesse caso, você deve receber webhooks na ordem abaixo:
Ordem de eventos quando startAt é hoje:
  1. subscription.created - Assinatura criada
  2. subscription.activated (se sucesso) ou subscription.cycle_failed (caso haja alguma inconsistência de dados na assinatura)
  3. subscription.unpaid (se todas as tentativas de cobrança da fatura falharem)

Webhooks de Cobrança

Quando o motor de assinaturas cria cobranças automaticamente, você também receberá os webhooks de cobrança padrão da Malga. Nestes casos, o subscriptionId estará presente no payload da cobrança para identificar a qual assinatura a cobrança pertence.

Exemplo de webhook de cobrança com subscriptionId

Esta documentação fornece uma base sólida para implementar webhooks de assinatura seguindo os padrões da Malga. Lembre-se de adaptar os exemplos para sua stack tecnológica específica e sempre testar em ambiente de desenvolvimento antes de ir para produção.