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?
- 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.
- 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.
- 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.
- 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
urlpara criar um webhook novo e já associá-lo à instância. Use na primeira instância. - Envie
webhook_idpara reutilizar um webhook que já existe. Use nas demais instâncias.
url
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.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.
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-IDpara separar as origens.
- 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_idretornado na criação; é ele que você reutiliza nas próximas instâncias. - Use o
namedo webhook para deixar claro o propósito (por exemplo, “CRM produção”). - No receptor, trate
X-Instance-IDcomo 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
Posso mudar a URL de uma instância sem afetar as outras?
Posso mudar a URL de uma instância sem afetar as outras?
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.Se eu desassociar um webhook de uma instância, ele some da conta?
Se eu desassociar um webhook de uma instância, ele some da conta?
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.Instâncias que compartilham o webhook precisam assinar os mesmos eventos?
Instâncias que compartilham o webhook precisam assinar os mesmos eventos?
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.Como sei qual instância enviou cada notificação?
Como sei qual instância enviou cada notificação?
Pelo cabeçalho
X-Instance-ID, presente em toda notificação. O X-Webhook-ID indica o webhook que fez a entrega.Posso enviar `url` e `webhook_id` na mesma requisição?
Posso enviar `url` e `webhook_id` na mesma requisição?
Envie apenas um dos dois. Se ambos forem informados, a Zapster prioriza o
webhook_id e ignora a url.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)
2,5^n, ondené o número da tentativa. - 1ª Tentativa: 2,5 segundos (
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 viaPOST 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):
POST que contenham os cabeçalhos X-Instance-ID, X-Message-ID, X-Attempt-Count e User-Agent com o prefixo Zapsterapi/.