Esta página apresenta os principais fluxos de eventos do Pix Automático e como eles são enviados via Webhook pelo Asaas.

Os webhooks permitem que a sua aplicação acompanhe automaticamente o ciclo de vida das autorizações e das cobranças recorrentes do Pix Automático, sem a necessidade de consultas constantes à API.

Além da sequência dos eventos, é importante compreender os comportamentos esperados, as dependências entre recursos e os possíveis cenários operacionais envolvidos.

Quando utilizar

Os webhooks do Pix Automático são recomendados para integrações que precisam:

Atualizar o status de autorizações em tempo real.
Identificar quando uma autorização foi ativada, expirada ou cancelada.
Acompanhar a criação e o processamento das instruções de pagamento.
Atualizar o status das cobranças recorrentes automaticamente.
Executar ações internas em resposta aos eventos recebidos.

Dependências do fluxo

Para que existam eventos relacionados às cobranças recorrentes do Pix Automático, é necessário que:

Uma autorização do Pix Automático tenha sido criada.
A autorização esteja ativa.
As cobranças sejam geradas normalmente.
As instruções de pagamento sejam enviadas ao banco pagador.

Caso a autorização seja cancelada ou expirada, as instruções de pagamento subsequentes poderão ser canceladas automaticamente.

📘
Importante
Os eventos de cobrança e instruções de pagamento dependem da existência de uma autorização ativa. Sem uma autorização válida, novos agendamentos não poderão ser processados.

Estrutura dos eventos

Todos os Webhooks do Pix Automático seguem o mesmo padrão utilizado pelos demais Webhooks do Asaas.

Embora cada evento possua informações específicas, alguns campos são especialmente importantes para a integração:

Campo	Finalidade
`event`	Identifica qual evento foi disparado.
`id`	Identificador do recurso relacionado ao evento.
`dateCreated`	Data de geração do evento.
`payment`	Identificador da cobrança, quando aplicável.
`pixAutomaticAuthorization`	Identificador da autorização relacionada ao Pix Automático.

📘
Importante
Recomenda-se utilizar os identificadores retornados pelo Webhook para correlacionar os eventos com os registros da sua aplicação, evitando depender apenas da ordem de recebimento dos eventos.

Boas práticas de integração

📘
Recomendado

Considere os Webhooks como assíncronos.

Não assuma que eventos diferentes chegarão exatamente no mesmo instante.

Utilize o identificador do evento para garantir idempotência.

Sempre responda HTTP 200 após processar o evento.

Implemente reprocessamento seguro para evitar duplicidade.

Mantenha seu endpoint disponível para receber novas tentativas de entrega.

Utilize os identificadores retornados no payload para correlacionar os eventos com sua base de dados.

Caso exista dúvida sobre o estado atual do recurso, consulte a API para obter o status mais recente.

Exemplo de evento

Os Webhooks enviados pelo Asaas seguem uma estrutura semelhante ao exemplo abaixo:

{
  "event": "PIX_AUTOMATIC_RECURRING_AUTHORIZATION_ACTIVATED",
  "id": "evt_123456",
  "dateCreated": "2026-07-10T14:32:18Z",
  "pixAutomaticAuthorization": "aut_987654",
  "payment": "pay_123456"
}

Os nomes dos campos podem variar conforme o evento recebido, mas a estrutura geral permanece a mesma.

Na implementação da integração, normalmente são utilizados:

o tipo do evento (event);
os identificadores retornados no payload;
o estado informado pelo recurso relacionado.

Comportamentos importantes

⚠️
Importante

Um mesmo evento pode ser reenviado em caso de falha na entrega.

Eventos devem ser processados de forma idempotente.

Os eventos representam mudanças de estado da autorização ou da instrução de pagamento.

O cancelamento de uma autorização pode gerar o cancelamento das instruções de pagamento relacionadas.

O pagamento de uma cobrança por outro meio pode provocar o cancelamento da instrução de pagamento automática.

Sobre os eventos de pagamento

O Pix Automático utiliza eventos financeiros já existentes na API do Asaas.

Por esse motivo, dependendo do fluxo representado, podem aparecer eventos financeiros diferentes.

Nos fluxos de autorização, o pagamento do QR Code imediato é representado pelo evento:

PAYMENT_RECEIVED

Já nos fluxos relacionados ao processamento da cobrança, a sequência apresentada representa apenas a evolução lógica do ciclo da instrução de pagamento.

Sempre utilize como referência o evento efetivamente recebido pelo Webhook da sua integração.

Fluxos das autorizações

As autorizações representam a permissão concedida pelo pagador para que cobranças recorrentes sejam processadas automaticamente.

Autorização concedida com sucesso

QR Code imediato criado, pagamento efetuado e autorização concedida:

PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CREATED
↓
PAYMENT_CREATED
↓
PAYMENT_RECEIVED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_ACTIVATED

Após a ativação, novas cobranças recorrentes poderão ser processadas automaticamente.

Autorização expirada

QR Code imediato criado, pagamento efetuado, autorização concedida e posteriormente expirada devido ao término da vigência definida em finishDate:

PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CREATED
↓
PAYMENT_CREATED
↓
PAYMENT_RECEIVED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_ACTIVATED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_EXPIRED

📘
Importante
Ao atingir a data configurada em finishDate, a autorização perde sua validade e novas cobranças não serão processadas.

QR Code expirado sem pagamento

QR Code criado, porém o pagamento não foi realizado:

PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CREATED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_REFUSED

Neste cenário, a autorização não é ativada.

Cancelamento realizado pelo pagador

PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CREATED
↓
PAYMENT_CREATED
↓
PAYMENT_RECEIVED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_ACTIVATED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CANCELLED

Após o cancelamento, novas cobranças recorrentes deixam de ser processadas.

Cancelamento realizado pelo cliente Asaas

PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CREATED
↓
PAYMENT_CREATED
↓
PAYMENT_RECEIVED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_ACTIVATED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CANCELLED

Independentemente da origem do cancelamento, o comportamento do fluxo é equivalente.

Fluxos das instruções de pagamento

As instruções de pagamento representam os agendamentos enviados ao banco pagador para execução da cobrança recorrente.

Pagamento realizado com sucesso

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PAYMENT_CONFIRMED

A cobrança foi executada normalmente.

Falha na execução por saldo ou limite insuficiente

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_REFUSED

Esse cenário pode ocorrer por falta de saldo ou limite disponível no banco do pagador.

Recusa do agendamento pelo banco pagador

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_REFUSED

Por exemplo, falhas operacionais podem impedir o agendamento da instrução.

Cancelamento pelo pagador

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CANCELLED

Cancelamento pelo cliente Asaas

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CANCELLED

Cobrança paga por outro meio

Caso a cobrança seja quitada manualmente, a instrução automática deixa de ser necessária:

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PAYMENT_CONFIRMED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CANCELLED

📘
Importante
O recebimento da cobrança por outro meio impede que a cobrança automática seja executada novamente.

Cancelamento da autorização

Quando uma autorização é cancelada, as instruções de pagamento relacionadas também podem ser canceladas:

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PIX_AUTOMATIC_RECURRING_AUTHORIZATION_CANCELLED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CANCELLED

Impactos operacionais

As aplicações que consomem os Webhooks do Pix Automático devem considerar que:

O cancelamento de uma autorização interrompe cobranças futuras.
A expiração da autorização impede novos agendamentos.
Uma instrução cancelada não significa necessariamente falha operacional, podendo ser consequência de pagamento realizado por outro meio.
Os eventos devem ser tratados de forma assíncrona e idempotente.
O estado final da cobrança deve ser determinado pelos eventos recebidos, e não apenas pela existência da instrução de pagamento.

Próximos passos

Após implementar os Webhooks do Pix Automático, recomendamos consultar:

Criação de autorizações do Pix Automático.
Criação de cobranças recorrentes.
Configuração de Webhooks.
Eventos do Pix Automático.
FAQ do Pix Automático.
Fila pausada e tentativas de entrega de Webhooks.