Como Receber Webhooks Instantaneamente — Antes do Deploy de Qualquer Código
Dá para receber webhooks instantaneamente — antes de fazer o deploy de qualquer código — porque plataformas modernas como o webhookbox.net criam uma URL de webhook funcionando na hora. Cole essa URL na plataforma parceira (um provedor de pagamento, o GitHub, qualquer serviço que envie webhooks) e as entregas começam a chegar imediatamente: armazenadas, inspecionáveis, pesquisáveis.
A parte que quase todo mundo perde é o que acontece depois. Essa URL é permanente — então, quando o seu servidor de verdade ficar pronto, você não reconfigura nada no parceiro. Cria um redirecionamento da caixa para o seu servidor, reenvia tudo o que ela já capturou, e a integração entra no ar sem o remetente perceber mudança alguma.
O ovo-e-galinha das integrações por webhook
Toda integração por webhook começa com o mesmo bloqueio: a plataforma parceira pede uma URL, e você ainda não tem uma. A resposta tradicional é construir primeiro — escrever um endpoint, fazer deploy, expor publicamente — tudo antes de ver um único payload real. Você acaba programando contra a documentação em vez de contra o que a plataforma realmente envia, e cada erro custa um novo deploy.
Uma caixa de captura de webhooks hospedada inverte essa ordem: primeiro você ganha a URL, observa o tráfego real, e só então escreve código. O fluxo completo é este.
Passo 1 — Pegue sua URL (na verdade, são duas)
- Abra o webhookbox.net. Uma caixa única é criada para você na hora — sem cadastro, sem cartão de crédito.
- Você recebe duas URLs do mesmo endpoint: uma de Desenvolvimento e uma de Produção. Use a de desenvolvimento para experimentar e a de produção na configuração real do parceiro — o ruído de teste nunca se mistura com o tráfego de verdade.
- Copie a URL e cole na plataforma que você quer integrar. Só isso.
Quanto tempo dura? Uma caixa anônima vive 7 dias (ou 500 requests). Crie uma conta grátis e a mesma URL vira permanente — sem reconfigurar nada do lado do parceiro. Veja planos e limites.
Passo 2 — Inspecione antes de escrever código
A partir desse momento, tudo o que o parceiro envia é capturado. Dispare um evento de teste do lado dele e abra a entrega no painel: headers completos, o payload JSON em árvore navegável, query params, headers de assinatura, metadados de origem. É aqui que você descobre como a integração realmente é — quais tipos de evento chegam, qual o formato do payload, qual o esquema de assinatura — antes de existir uma única linha de código de servidor.
Quando você começar a programar, estará programando contra payloads reais que já viu — não contra a sua melhor interpretação da documentação.
Servidor pronto? Não toque na integração
Digamos que agora você construa um servidor Node para processar os eventos. Normalmente é aqui que você voltaria à plataforma parceira para trocar a URL. Com uma caixa permanente, você não muda nada na integração:
- Crie um redirecionamento permanente. No painel, aponte o encaminhamento do seu endpoint para o seu servidor. Dali em diante, cada entrega é capturada e encaminhada automaticamente — o parceiro continua enviando para a mesma URL configurada no primeiro dia.
- Reenvie o backlog. E os webhooks que chegaram antes de o servidor existir? Estão todos armazenados. Reenvie-os em lote para o novo destino e o seu servidor processa o histórico como se estivesse online desde o início.
Entrar em produção vira um interruptor que você liga do seu lado. Sem coordenação com o parceiro, sem janela de propagação, sem e-mail de "por favor, reenvia aqueles eventos".
Por que manter a caixa em produção
Aqui entra a segunda ideia, e é a que rende por anos: quando a integração estiver funcionando, não remova a caixa. Mantenha-a na frente do seu servidor como intermediário permanente.
Essa arquitetura te dá três garantias:
- O parceiro sempre vê sucesso. Cada entrega chega ao WebhookBox e recebe um HTTP 200 de volta. No dashboard do remetente a integração está verde — mesmo enquanto o seu servidor está em deploy, reiniciando ou sendo depurado.
- Nada se perde, nunca. Se o seu servidor falhar ao processar uma entrega encaminhada, a cópia armazenada continua lá. O encaminhamento tenta de novo com backoff, e você reenvia sob demanda depois de corrigir o bug. Compare com ir direto: plataformas como o Stripe repetem entregas falhas por uma janela limitada, e o GitHub só mantém entregas disponíveis para reenvio por tempo limitado — depois disso, o evento se foi.
- Você depura sem pedir nada a ninguém. Inspecione o payload exato que causou o bug, corrija o handler, reenvie aquela mesma entrega — tudo do seu lado. Sem ticket de suporte para o parceiro, sem esperar a próxima ocorrência de um evento raro.
Em outras palavras: a caixa que desbloqueou o primeiro minuto da sua integração vira, em produção, a camada que transforma falha de webhook em não-evento. Você começou com ela porque era instantânea; você a mantém porque ela coloca você no controle da reentrega — e não o seu parceiro.
Quer ver o mesmo fluxo aplicado a uma plataforma concreta, campo a campo? Leia como criar um GitHub App (e preencher a Webhook URL).
FAQ
Preciso de um servidor para receber webhooks?
Para começar, não. Uma caixa de captura hospedada como o WebhookBox te dá uma URL funcionando na hora: cole na plataforma parceira e cada entrega é recebida, armazenada e inspecionável. O servidor próprio só é necessário quando você quiser executar código em resposta aos eventos — e aí dá para encaminhar ou reenviar tudo o que a caixa já capturou.
Por que eu ganho duas URLs (desenvolvimento e produção)?
São dois ambientes do mesmo endpoint. Use a URL de desenvolvimento enquanto experimenta e a de produção na configuração real do parceiro — o ruído de teste nunca se mistura com o tráfego de verdade, e você inspeciona cada fluxo separado.
O que acontece com os webhooks recebidos antes de o meu servidor existir?
Ficam todos armazenados na caixa. Quando o servidor entrar no ar, reenvie-os em lote para o novo destino: o servidor processa o backlog como se estivesse lá desde o primeiro dia, sem pedir nada ao parceiro.
O remetente percebe que existe um intermediário na frente do meu servidor?
Não. O parceiro entrega na sua URL do WebhookBox, recebe HTTP 200 e marca a entrega como bem-sucedida — do ponto de vista dele, a integração está simplesmente saudável. O que acontece depois (encaminhamento, retries, reenvios ao seu servidor) fica inteiramente sob o seu controle.
E se o meu servidor estiver fora do ar quando um webhook chegar?
A entrega não se perde. O WebhookBox já aceitou e armazenou, o encaminhamento tenta de novo com backoff, e você pode reenviar manualmente depois do incidente — sem pedir reenvio ao parceiro. A maioria das plataformas só repete entregas falhas por tempo limitado, então é a cópia armazenada que te salva.