Nó: Webhook de Saída
O nó Webhook de Saída realiza uma chamada HTTP para uma URL externa durante a execução do workflow. Com ele, você pode integrar o Hashdata com qualquer sistema que possua uma API REST — sem precisar de um conector nativo dedicado. Sempre que uma instância passar por esse nó, o Hashdata envia uma requisição para o endereço configurado e aguarda a resposta antes de prosseguir para o próximo passo.
Esse nó é a ponte universal entre os seus processos no Hashdata e o mundo externo: CRMs, ERPs, sistemas de suporte, plataformas de e-commerce, automações internas e qualquer outro serviço que aceite requisições HTTP.
Quando Usar
O nó de Webhook de Saída é indicado nas seguintes situações:
- Integrar com sistemas sem conector nativo: quando o serviço que você precisa acionar não possui uma integração pronta no Hashdata (como Slack, Google Sheets ou Teams), o webhook permite comunicação direta via API.
- Acionar automações em CRM ou ERP: ao receber uma resposta de formulário, você pode criar automaticamente um contato no seu CRM, abrir um chamado no ERP ou atualizar um registro em qualquer sistema com API REST.
- Enviar dados em tempo real: em vez de exportações periódicas, o webhook garante que os dados chegam ao sistema de destino no exato momento em que a instância passa por esse nó.
- Sincronizar sistemas: mantenha dois sistemas sincronizados disparando chamadas a APIs de terceiros conforme o fluxo avança.
- Notificar plataformas externas: informe sistemas de monitoramento, plataformas de BI ou ferramentas de comunicação sobre eventos ocorridos dentro do workflow.
Configuração
Para configurar o nó, clique sobre ele no canvas do editor de workflow. O painel lateral exibirá as opções abaixo.
| Campo | Obrigatório | Descrição |
|---|---|---|
| URL | Sim | Endereço completo da API que receberá a requisição. Deve começar com https://. URLs com HTTP simples não são aceitas por razões de segurança. |
| Método HTTP | Sim | Verbo HTTP da requisição: GET, POST, PUT, PATCH ou DELETE. Escolha conforme a documentação da API de destino. |
| Tipo de conteúdo | Somente para POST e PATCH | Define o formato do corpo da requisição. Opções: JSON (application/json) ou Formulário URL-encoded (application/x-www-form-urlencoded). Consulte a documentação da API destino para saber qual formato ela espera. |
| Headers | Não | Pares de chave e valor enviados no cabeçalho da requisição. Use para autenticação (ex: Authorization: Bearer SEU_TOKEN) ou para instruções específicas da API (ex: Content-Type, Accept, x-api-key). |
| Parâmetros de URL | Não | Query string parameters adicionados automaticamente ao final da URL. Por exemplo, adicionar a chave status com valor ativo resultará em ?status=ativo na URL final. |
| Estrutura do corpo (body) | Sim | Simples (campos personalizáveis): nesta opções o usuário poderá escolher quais informações deseja enviar para o sistema externo. Resposta Completa: nesta opção o sistema enviará todas as informações disponíveis de um formulário, ou seja, o usuário não precisa escolher um por um. |
O Hashdata rejeita URLs que utilizem HTTP simples. Certifique-se de que a API de destino possui um certificado SSL válido e que a URL começa com https://. Essa restrição existe para proteger dados sensíveis que trafegam entre o Hashdata e sistemas externos.
Saídas do Nó
O nó de Webhook de Saída possui duas saídas no canvas, e você deve conectar cada uma ao tratamento adequado:
- Sucesso: acionada quando a API responde com um código HTTP na faixa 2xx (200, 201, 204, etc.). Indica que a chamada foi realizada e aceita pelo sistema de destino. O fluxo segue normalmente por essa saída.
- Erro: acionada quando a API responde com um código HTTP fora da faixa 2xx (ex: 400, 401, 403, 404, 500) ou quando ocorre uma falha de rede (timeout, host inacessível, erro de DNS). Use essa saída para tratar falhas — por exemplo, enviando uma notificação por email ou acionando um fluxo alternativo.
Conectar ambas as saídas é considerado boa prática. Se a saída de Erro ficar desconectada, instâncias que falham nesse nó podem ficar presas ou encerrar sem tratamento adequado.
Autenticação
A maioria das APIs exige alguma forma de autenticação para aceitar requisições externas. O nó de Webhook de Saída suporta os mecanismos mais comuns por meio dos Headers:
Token Bearer (OAuth 2.0 / JWT)
Adicione um header com a chave Authorization e o valor Bearer SEU_TOKEN_AQUI. Substitua SEU_TOKEN_AQUI pelo token de acesso fornecido pela API de destino.
API Key no Header
Muitas APIs utilizam uma chave de API transmitida em um header específico. Consulte a documentação da API para saber o nome correto do header — exemplos comuns são x-api-key, api-key ou X-Auth-Token. Adicione o par chave-valor correspondente na seção de headers do nó.
API Key na URL
Algumas APIs aceitam a chave de API como parâmetro de URL. Nesse caso, use a seção Parâmetros de URL para adicionar o par chave-valor, mantendo a chave fora do campo de URL principal para facilitar a manutenção.
Evite embutir credenciais, tokens ou chaves de API diretamente no campo de URL (como https://api.exemplo.com?token=MINHA_CHAVE). URLs podem ser registradas em logs de acesso e ficar expostas inadvertidamente. Use sempre o campo de Headers ou Body com POST para informações sensíveis, e prefira os headers para autenticação.
Segurança
Ao configurar o nó de Webhook de Saída, siga estas boas práticas para garantir a segurança das suas integrações:
- Use somente HTTPS: garanta que a API de destino suporta conexões seguras. O Hashdata bloqueia chamadas para URLs HTTP.
- Mantenha tokens nos headers: credenciais e chaves de API devem estar sempre no campo de Headers, nunca na URL ou no corpo da requisição em texto plano.
- Revogue tokens não utilizados: se um workflow for desativado ou a integração não for mais necessária, revogue o token de acesso no sistema de destino.
- Prefira tokens de escopo limitado: ao gerar credenciais para o webhook, conceda apenas as permissões estritamente necessárias para a operação que o nó realiza.
- Monitore a saída de Erro: acompanhe instâncias que passam pela saída de Erro para detectar tentativas de chamada com credenciais expiradas ou APIs indisponíveis.
Timeout e Tratamento de Falhas
O Hashdata aguarda no máximo 10 segundos pela resposta da API de destino. Se a API demorar mais do que isso para responder, a chamada é encerrada e a instância segue pela saída de Erro. APIs lentas, sobrecarregadas ou geograficamente distantes podem causar timeouts frequentes. Nesse caso, verifique a performance da API de destino ou considere usar uma fila assíncrona no sistema receptor.
Para lidar com falhas de forma robusta no seu workflow:
- Conecte a saída de Erro a um nó de Enviar Email para notificar responsáveis sobre a falha.
- Use um nó de Definir Status para registrar que a instância aguarda intervenção manual.
- Considere adicionar um nó de Aprovação na saída de erro, permitindo que um administrador decida como prosseguir.
Exemplos de Uso
- Criar lead no CRM: ao receber uma resposta de formulário de interesse, disparar um POST para a API do CRM com os dados do respondente e registrar o ID do lead criado via modo full-response.
- Abrir chamado no sistema de suporte: quando uma aprovação é concluída com resultado negativo, enviar os detalhes para a API do sistema de suporte para abertura automática de um ticket.
- Notificar sistema de logística: ao receber um pedido via formulário, acionar a API do sistema de logística para iniciar a separação do produto.
- Sincronizar com ERP: após uma aprovação de orçamento, enviar os dados aprovados para a API do ERP e usar o número do documento gerado nos próximos nós do workflow.