Webhook

O trigger Webhook executa um workflow sempre que uma requisição HTTP chega a uma URL que o Studio gera para ele. Use-o para iniciar um workflow a partir de qualquer serviço externo ou aplicação própria capaz de enviar uma requisição HTTP — quando não existe um trigger de integração dedicado.

Como funciona

  1. Adicione o trigger Webhook como ponto de entrada do workflow.
  2. Copie a URL de webhook única que o Studio gera.
  3. Aponte seu serviço externo para ela com um POST.
  4. Cada requisição enviada à URL executa o workflow, com o payload da requisição disponível para os blocks seguintes.

Configuração

Input Format

Defina, se quiser, o formato JSON que você espera receber. Os campos ficam documentados no block e são lidos pelo nome nos blocks seguintes. Use um campo file[] para uploads.

Autenticação

Ative Require Authentication e defina um token. Quem chama envia o token como Bearer token no header Authorization, ou você indica um header personalizado (como X-Secret-Key) e o token é comparado com esse header.

Resposta

Por padrão, o endpoint apenas confirma o recebimento. Troque para uma resposta personalizada para devolver seu próprio código de status e corpo JSON a quem chamou.

Saídas

A requisição é interpretada e disponibilizada para o resto do workflow — os campos do corpo pelo nome (um userId no corpo é lido como <webhook.userId>), além dos headers e dos parâmetros de query. Campos comuns como event, id e data são extraídos do payload quando estão presentes.

Comportamento

  • Deduplicação — verificações de idempotência evitam execuções duplicadas a partir de requisições idênticas repetidas.
  • Limite de taxa — proteção nativa contra abuso.
  • Deploy obrigatório — a URL só dispara depois que o workflow é deployado; antes disso, ela retorna não encontrado.
  • Sem desativação automática — diferente dos triggers de polling (RSS, Gmail, IMAP), um webhook de push processa cada requisição de forma independente e não se desativa após execuções que falham.

Valide e sanitize os dados recebidos pelo webhook antes de usá-los nos blocks seguintes.

Teste

Envie uma requisição para a URL do webhook com curl (ou Postman) e acompanhe a execução aparecer em Logs:

curl -X POST "<your webhook URL>" \
  -H "Content-Type: application/json" \
  -d '{"event": "test", "userId": "123"}'

Abra a execução para confirmar que o payload chegou do jeito que os blocks seguintes esperam — que <webhook.userId> resolve e que a autenticação rejeita uma requisição sem o token, caso você a tenha ativado.

Triggers de serviço

Muitas integrações também podem funcionar como triggers: ative Use as Trigger em um block de serviço (Slack, GitHub, Stripe e outros) para registrar um webhook específico daquele serviço, com filtro de eventos e dados estruturados — sem precisar montar um endpoint genérico.

Veja Triggers para todos os serviços que oferecem isso.

Common Questions

POST executa workflows. GET é usado apenas para desafios de verificação específicos de provedores (como Microsoft Graph ou WhatsApp). Outros métodos retornam 405 Method Not Allowed.
Ative Require Authentication e defina um Authentication Token. Quem chama envia o token como Bearer token no header Authorization, ou você indica o nome de um header personalizado (por exemplo, X-Secret-Key) e o token é comparado com esse header.
Sim. O campo Input Format permite definir o schema JSON esperado. É opcional, mas documenta a estrutura, e você pode usar um campo file[] para uploads.
Sim. O pipeline de processamento inclui verificações de idempotência que evitam execuções duplicadas a partir de requisições repetidas com o mesmo payload.
Todos — headers, corpo e parâmetros de query são interpretados e ficam disponíveis para os blocks seguintes. Campos comuns como event, id e data são extraídos do payload quando estão presentes.
Sim. O endpoint verifica se o workflow está deployado antes de iniciar uma execução; caso contrário, retorna uma resposta de não encontrado.
Não. Diferente dos triggers baseados em polling (RSS, Gmail, IMAP), webhooks de push não se desativam automaticamente — cada requisição é processada de forma independente. Se as execuções falharem de forma consistente, confira os logs de execução.
ScheduleFeed RSS