Skip to main content

O que são Webhooks?

Webhooks são uma maneira eficiente e automatizada de uma aplicação enviar dados em tempo real para outra aplicação. Eles permitem que sistemas diferentes comuniquem eventos específicos sem a necessidade de uma solicitação ativa da aplicação receptora. Em vez disso, a aplicação que gera o evento envia uma notificação, normalmente na forma de uma solicitação HTTP POST, para uma URL previamente configurada pela aplicação receptora.

O que os Webhooks fazem?

Os Webhooks são usados para notificar sua aplicação sobre eventos que ocorrem em outra aplicação ou serviço. Algumas das tarefas comuns realizadas por Webhooks incluem:
  • Notificações em Tempo Real: A aplicação receptora é imediatamente notificada quando algo acontece, como a criação de um novo pedido, uma mudança de status, ou uma nova mensagem.
  • Automação de Processos: Permitem automatizar respostas ou ações em sua aplicação quando certos eventos ocorrem, sem a necessidade de consultas constantes à API.
  • Integração entre Sistemas: Facilitam a integração entre sistemas diferentes, permitindo que eventos em um sistema desencadeiem ações automáticas em outro.

Como os Webhooks funcionam?

  1. Configuração: Primeiro, a aplicação receptora deve configurar um endpoint (uma URL pública) que estará pronto para receber as notificações via Webhook.
  2. Registro do Webhook: A aplicação emissora precisa ser configurada para enviar notificações para o endpoint do Webhook sempre que um evento específico ocorrer.
  3. Envio do Evento: Quando o evento configurado ocorre, a aplicação emissora envia uma solicitação HTTP POST para o endpoint do Webhook, incluindo no corpo da requisição os dados relevantes sobre o evento.
  4. Processamento do Evento: A aplicação receptora processa a informação recebida e pode executar várias ações em resposta ao evento, como atualizar um banco de dados, enviar um e-mail, ou disparar outro processo interno.

Um webhook, várias instâncias

Um webhook na Zapster é um destino que você cadastra uma vez (a URL que vai receber os eventos) e reaproveita em quantas instâncias quiser. Cada instância decide, por conta própria, quais eventos quer receber naquele destino. Vale entender dois conceitos que trabalham juntos:
  • O webhook (na sua conta): guarda a URL, um nome e o status (ligado ou desligado). É o endereço para onde as notificações são enviadas. Ele pertence à sua conta, não a uma instância específica.
  • A associação com cada instância: toda instância que usa o webhook ganha sua própria associação. É nela que ficam os eventos assinados e os ajustes daquela instância (ativar/desativar, modo de teste). Um mesmo webhook pode estar associado a várias instâncias ao mesmo tempo.

Por que compartilhar um webhook

O principal motivo é manutenção centralizada. Se você tem dezenas de instâncias enviando eventos para o mesmo sistema, cadastrar a URL uma única vez e reutilizá-la evita repetir configuração. Quando a URL precisar mudar (troca de servidor, novo domínio, ajuste de rota), você altera em um só lugar e a mudança vale para todas as instâncias que usam aquele webhook.

Como fazer na prática

O mesmo endpoint (POST /wa/instances/:id/webhooks) cobre os dois caminhos. A diferença está no corpo da requisição:
  • Envie url para criar um webhook novo e já associá-lo à instância. Use na primeira instância.
  • Envie webhook_id para reutilizar um webhook que já existe. Use nas demais instâncias.
O corpo aceita url OU webhook_id, nunca os dois juntos. Se ambos forem enviados, a Zapster prioriza o webhook_id. O campo events é sempre obrigatório e precisa ter pelo menos um evento.
1. Primeira instância: crie o webhook com url
2. Demais instâncias: reutilize com webhook_id Use o webhook_id devolvido no passo anterior para associar o mesmo webhook a outra instância. Note que os eventos podem ser diferentes: cada instância assina o que faz sentido para ela.

Editar e remover: o que muda

Como o webhook e a associação são coisas distintas, editar ou remover tem escopos diferentes. Vale conhecer cada operação antes de aplicar mudanças em produção.
Editar o webhook propaga para todo mundo. Alterar a URL ou o nome pelo endpoint de conta (PATCH /webhooks/:id) afeta todas as instâncias associadas. Se você precisa de uma URL diferente para apenas uma instância, crie um webhook novo em vez de editar o existente.
Desassociar não é o mesmo que excluir. DELETE /wa/instances/:id/webhooks/:whId apenas desliga o webhook daquela instância; ele continua ativo nas outras e na sua conta. Para apagar o webhook de vez, use DELETE /webhooks/:id.

Como diferenciar a origem no receptor

Cada instância entrega os eventos de forma independente, mesmo quando compartilham o mesmo webhook. Para saber de onde veio cada notificação, use os cabeçalhos HTTP:
  • X-Instance-ID: identifica a instância que gerou o evento (a origem real).
  • X-Webhook-ID: identifica o webhook compartilhado que entregou a notificação.
Como os eventos assinados podem ser diferentes em cada instância, o mesmo webhook pode receber message.received de uma instância e message.sent de outra. Sempre olhe o X-Instance-ID para rotear ou registrar o evento corretamente.

Quando compartilhar e quando separar

Compartilhar um webhook faz sentido quando:
  • Todas as instâncias entregam para o mesmo sistema (um CRM, uma fila, um endpoint central).
  • Você quer trocar a URL de destino em um só lugar no futuro.
  • O processamento no receptor já usa o X-Instance-ID para separar as origens.
Webhooks distintos por instância fazem mais sentido quando:
  • Cada instância pertence a um cliente ou produto diferente, com URL própria.
  • Você precisa ligar ou desligar o destino de uma instância sem tocar nas outras.
  • Ambientes separados (produção e homologação) não devem se misturar.

Boas práticas

  • Guarde o webhook_id retornado na criação; é ele que você reutiliza nas próximas instâncias.
  • Use o name do webhook para deixar claro o propósito (por exemplo, “CRM produção”).
  • No receptor, trate X-Instance-ID como a fonte da verdade sobre a origem do evento.
  • Antes de editar a URL de um webhook compartilhado, confirme quais instâncias serão afetadas com o endpoint de listagem de webhooks.

Perguntas frequentes

Não pelo endpoint de edição do webhook, que é de conta e propaga para todas as instâncias associadas. Para uma URL exclusiva, crie um webhook novo enviando url na criação e associe apenas à instância desejada.
Não. DELETE /wa/instances/:id/webhooks/:whId só desliga o webhook daquela instância. Ele continua ativo nas demais e na sua conta. Para apagar de vez, use DELETE /webhooks/:id.
Não. Os eventos são definidos por instância, na associação. Uma pode assinar message.received e outra message.sent, mesmo apontando para o mesmo webhook.
Pelo cabeçalho X-Instance-ID, presente em toda notificação. O X-Webhook-ID indica o webhook que fez a entrega.
Envie apenas um dos dois. Se ambos forem informados, a Zapster prioriza o webhook_id e ignora a url.
Para os detalhes de cada endpoint, consulte a referência da API: criar/associar webhook, editar associação da instância, desassociar da instância, editar o webhook e excluir o webhook.

Tratamento de Falhas e Retentativas

Em um cenário ideal, a aplicação receptora recebe e processa a solicitação do Webhook sem problemas. No entanto, falhas podem ocorrer devido a vários fatores, como indisponibilidade do servidor, problemas de rede, ou erros de processamento. Para garantir que as notificações importantes não sejam perdidas, implementamos um mecanismo de retentativa. Se a aplicação receptora responder com um código de status HTTP maior que 400 (indicando um erro), a aplicação emissora tentará reenviar a notificação do Webhook até 5 vezes.

Detalhes da Retentativa

  • Critério de Falha: Qualquer resposta com código de status HTTP maior ou igual que 400.
  • Número de Retentativas: Até 5 tentativas.
  • Intervalo entre Retentativas: O intervalo entre cada retentativa aumenta progressivamente usando um fator de 2,5. Os intervalos em segundos são os seguintes:
    • 1ª Tentativa: 2,5 segundos (2.5^1)
    • 2ª Tentativa: ~6 segundos (2.5^2)
    • 3ª Tentativa: ~15 segundos (2.5^3)
    • 4ª Tentativa: ~39 segundos (2.5^4)
    • 5ª Tentativa: ~97 segundos (2.5^5)
    Cada intervalo é calculado como 2,5^n, onde n é o número da tentativa.

Cabeçalhos HTTP Personalizados

Todas as notificações de webhook enviadas pela Zapster API incluem cabeçalhos HTTP personalizados que identificam a origem e o contexto do evento. Esses cabeçalhos são úteis para validação, logging e configuração de regras de firewall.

Validação e Allowlisting

Você pode utilizar os cabeçalhos HTTP personalizados para validar a origem das notificações recebidas. Como o webhook é entregue via POST no seu servidor, os exemplos abaixo mostram o endpoint receptor em cada linguagem (cURL e código de navegador não recebem webhooks, por isso não aparecem aqui):
Allowlisting em WAF/Firewall: Se você utiliza um Web Application Firewall (WAF) ou regras de firewall, configure-o para aceitar requisições POST que contenham os cabeçalhos X-Instance-ID, X-Message-ID, X-Attempt-Count e User-Agent com o prefixo Zapsterapi/.