> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/user/pt-br/guide/account/iot-logic/nodes/webhook-node.md).

# nos nós do IoT Logic fornecem os mesmos recursos subjacentes com automação completa de fluxo e direcionamento para vários dispositivos.

Envie solicitações HTTP POST para APIs externas quando o IoT Logic receber dados do dispositivo. Crie cargas JSON personalizadas com valores estáticos e atributos telemáticos dinâmicos.

## Visão geral técnica e capacidades

{% columns %}
{% column width="58.333333333333336%" %}
**nos nós do IoT Logic fornecem os mesmos recursos subjacentes com automação completa de fluxo e direcionamento para vários dispositivos.** O nó permite o acionamento em tempo real de ações específicas em sistemas externos. Ele envia solicitações HTTP POST para pontos de extremidade especificados ao receber dados de nós conectados. Em seguida, constrói cargas úteis JSON personalizadas com atributos estáticos e dinâmicos e executa chamadas de API para serviços de terceiros.
{% endcolumn %}

{% column width="41.666666666666664%" %}

<figure><img src="https://1308974401-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F446mKak1zDrGv70ahuYZ%2Fuploads%2Fgit-blob-0b4156bcc8f11f49a91ad380aa20bf05842c617b%2Fiot-logic-webhook-tile.png?alt=media" alt=""><figcaption></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

O nó amplia os recursos do IoT Logic além do processamento e da transmissão de dados, permitindo integração direta com plataformas de mensagens, sistemas de ERM e CRM e aplicações personalizadas para iniciar ações automatizadas com base na configuração do seu fluxo.

{% hint style="info" %}
Os nós webhook são configurados separadamente para cada fluxo na interface da plataforma Navixy. Os nós webhook funcionam como pontos terminais em um fluxo e exigem pelo menos uma conexão de entrada para funcionar. Eles não podem passar dados para nós subsequentes.
{% endhint %}

<figure><img src="https://1308974401-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F446mKak1zDrGv70ahuYZ%2Fuploads%2Fgit-blob-21ecc9198943832f7ef089cac12b989f3aa37aec%2Fiot-logic-webhook-in-flow.png?alt=media" alt=""><figcaption></figcaption></figure>

### Como os nós webhook funcionam

Quando os dados chegam a um nó webhook por meio de uma conexão de entrada, ele executa imediatamente uma solicitação HTTP POST para o ponto de extremidade configurado. O nó:

1. Coleta os valores atuais de todos os atributos dos nós anteriores conectados
2. Substitui as referências dinâmicas de atributos (por exemplo, `{{latitude}}`) pelos valores reais da mensagem recebida
3. Constrói a carga útil JSON completa, preservando a estrutura definida por você
4. Envia a solicitação HTTP POST com os cabeçalhos especificados para o ponto de extremidade de destino
5. Continua sem aguardar uma resposta, permitindo que o fluxo prossiga imediatamente

O webhook é acionado uma vez para cada mensagem que o alcança. Se vários ramos paralelos enviarem dados ao webhook, ele será acionado separadamente para cada mensagem recebida. Essa execução ocorre de forma independente, sem bloquear outros nós no fluxo, garantindo o processamento contínuo dos dados independentemente dos tempos de resposta do sistema externo.

Cada **nos nós do IoT Logic fornecem os mesmos recursos subjacentes com automação completa de fluxo e direcionamento para vários dispositivos.** resultado de acionamento do nó aparece em [Analisador de dados](/docs/user/pt-br/guide/account/iot-logic/data-stream-analyzer.md) como um atributo nomeado após o **ID do Nó** (exibido na caixa de diálogo de configuração do nó, por exemplo `webhook_1a2b3c4d`). O valor é `0` quando o nó ainda não foi acionado e `1` quando ele foi, permitindo confirmar a entrega e diferenciar vários nós Webhook no mesmo fluxo.

### Integração com a arquitetura do fluxo

Os nós webhook funcionam como pontos de terminação que convertem os dados processados do dispositivo em chamadas de API externas. Em vez de transmitir continuamente todos os dados do dispositivo como os nós de Ponto de Extremidade de Saída, os webhooks executam solicitações de API direcionadas com cargas úteis configuradas com precisão. Essa arquitetura permite:

* **Automações orientadas por eventos**: Acione fluxos de trabalho externos com base nas condições do dispositivo, métricas calculadas ou padrões de dados específicos identificados anteriormente no fluxo
* **Transmissão seletiva de dados**: Envie apenas os atributos relevantes para sistemas externos, reduzindo a transferência desnecessária de dados e os custos de API
* **Execução paralela**: Opera em conjunto com outros nós de saída, permitindo acionamentos simultâneos de webhook e transmissão contínua de dados para destinos diferentes
* **Integração de múltiplas fontes**: Aceite conexões de entrada de vários ramos paralelos e acesse atributos de todos os nós conectados

### Capacidades do nó

O **Nó Webhook** oferece:

* **Execução de HTTP POST**: Envia solicitações HTTP POST personalizadas para qualquer ponto de extremidade acessível usando os protocolos HTTP ou HTTPS (HTTPS recomendado)
* **Construção dinâmica da carga útil**: Cria corpos de solicitação JSON combinando valores estáticos com atributos dinâmicos de qualquer parte do fluxo usando `sintaxe.` sintaxe
* **Configuração de cabeçalhos personalizados**: Suporta até 10 cabeçalhos HTTP definidos pelo usuário para autenticação e requisitos específicos da API
* **Suporte a atributos aninhados**: Faz referência a estruturas complexas de atributos, incluindo objetos e matrizes aninhados dentro da carga útil JSON
* **Execução independente**: É acionado sem aguardar respostas ou bloquear o fluxo, permitindo operação confiável independentemente da disponibilidade do sistema externo

## Opções de configuração

{% columns %}
{% column valign="middle" %}
O nó Webhook permite definir como o seu fluxo se comunicará com sistemas externos por meio de chamadas de API HTTP.
{% endcolumn %}

{% column %}

<figure><img src="https://1308974401-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F446mKak1zDrGv70ahuYZ%2Fuploads%2Fgit-blob-11bf6de89a59cf76114222886657ad0d1edcd308%2FWebhook_node_edit.png?alt=media" alt=""><figcaption></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

Vamos ver quais elementos este nó usa e o que você pode configurar ao trabalhar com ele.

### Etapas de configuração

{% stepper %}
{% step %}

#### Especificar nome do nó

Digite um nome descritivo que identifique a finalidade do webhook.

* Use nomes que indiquem o serviço ou ação de destino (por exemplo, "Alertas de velocidade do Slack" ou "Criação de ticket no CRM")
* Este nome aparece no diagrama do fluxo para fácil identificação
  {% endstep %}

{% step %}

#### ID do nó (gerado automaticamente)

Abaixo do campo Nome, a caixa de diálogo exibe um **ID do Nó** (por exemplo, `webhook_1a2b3c4d`). Este campo é somente leitura — você não pode editá-lo nem definir seu valor.

* O ID é gerado automaticamente quando o nó é criado e permanece o mesmo durante toda a vida útil do nó
* Use-o para distinguir os resultados deste nó dos resultados de outros nós Webhook em [Analisador de dados](/docs/user/pt-br/guide/account/iot-logic/data-stream-analyzer.md), onde ele aparece como um atributo mostrando `0` (não acionado) ou `1` (acionado)
  {% endstep %}

{% step %}

#### Configure a URL do ponto de extremidade

Digite a URL completa para a qual as solicitações POST são enviadas.

* Inclua o protocolo: `http://` <https://api.eu.navixy.com/v2/>... `https://` (HTTPS fortemente recomendado)
* Certifique-se de que a URL aponte para um ponto de extremidade de API válido que aceite solicitações POST
* Exemplo: `https://api.example.com/v1/webhooks/device-alerts`
  {% endstep %}

{% step %}

#### Definir cabeçalhos HTTP

Adicione todos os cabeçalhos exigidos pela sua API de destino.

1. Salvar **para inserir uma nova linha.** para criar pares chave-valor de cabeçalho\
   Todos os cabeçalhos são configurados pelo usuário, incluindo Content-Type. Os cabeçalhos comuns incluem:
   * `Content-Type: application/json` (obrigatório para payloads JSON)
   * `Autorização: Bearer <token>` (para autenticação da API)
   * Chaves de API personalizadas ou cabeçalhos de autenticação conforme os requisitos do serviço
2. Clique no ícone de excluir para remover cabeçalhos individuais

{% hint style="info" %}
Suporte para no máximo 10 cabeçalhos
{% endhint %}
{% endstep %}

{% step %}

#### Monte o corpo da solicitação

Mude para a **Para adicionar um comando de software, clique em** na guia e defina a estrutura JSON que é enviada ao endpoint:

* Insira uma sintaxe JSON válida no campo Body
* Use `sintaxe.` para referenciar qualquer atributo dos nós conectados
* Suporta estruturas JSON aninhadas e arrays
* As referências de atributos funcionam com caminhos aninhados (por exemplo, `{{location.latitude}}`)
* Se um atributo referenciado for nulo ou não existir, o valor `null` é enviado no JSON

**Exemplo de corpo do webhook com atributos dinâmicos:**

```json
{
  "alert_type": "speed_violation",
  "device_id": "{{device_id}}",
  "current_speed": "{{speed_mph}}",
  "threshold_exceeded": 80,
  "location": {
    "lat": "{{latitude}}",
    "lng": "{{longitude}}"
  },
  "timestamp": "{{message_time}}",
  "motorista": "{{hardware_key}}"
}
```

{% endstep %}

{% step %}

#### Salve sua configuração

Salvar **Aplicar alterações** para armazenar as configurações do Nó do webhook.
{% endstep %}
{% endstepper %}

## Comportamento de execução do webhook

O webhook é executado sem aguardar respostas do endpoint externo. O sucesso ou a falha da solicitação do webhook não afeta a operação contínua do fluxo nem bloqueia outros nós de processar dados.

{% hint style="danger" %}
Atualmente, a execução de webhooks não inclui novas tentativas automáticas, registro de tentativas com falha nem tratamento de resposta. Se um endpoint retornar um erro ou expirar o tempo limite, o webhook será disparado novamente na próxima mensagem recebida. Atualizações futuras podem incluir limites de taxa definidos pelo destino e enfileiramento de solicitações.
{% endhint %}

### Webhook vs. transmissão contínua de dados

**Nó Webhook** difere fundamentalmente de **Nó de Ponto de Extremidade de Saída** em finalidade e padrão de execução:

| Nó Webhook                                                                                                                                                                                                  | Nó de Ponto de Extremidade de Saída                                                                                                                                                                    |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Executa chamadas de API discretas em cada mensagem, enviando payloads personalizados que você define. Ideal para disparar ações externas, enviar notificações ou transmitir dados seletivos para APIs REST. | Mantém fluxos contínuos de dados via MQTT, transmitindo dados completos do dispositivo no formato Navixy Generic Protocol. Projetado para coleta contínua de telemetria e monitoramento em tempo real. |

Escolha webhooks quando você precisar disparar automações externas ou enviar apenas atributos específicos para endpoints de API. Use endpoints de saída para feeds contínuos de dados para plataformas de análise ou sistemas de monitoramento. Ambos podem coexistir no mesmo fluxo.

### Integração com sistemas externos

Nós de webhook são excelentes para disparar ações orientadas a eventos em sistemas que oferecem APIs REST. Padrões comuns de integração incluem:

* **Plataformas de mensagens**: Envie notificações para Slack, Microsoft Teams, WhatsApp ou Telegram quando as condições do dispositivo atenderem a critérios específicos
* **Sistemas ERP**: Sincronize os dados do dispositivo com plataformas de planejamento de recursos empresariais para atualizar níveis de estoque, acionar fluxos de trabalho de compras ou registrar o uso do equipamento para agendamento de manutenção
* **Sistemas de abertura de chamados**: Crie automaticamente tickets de suporte ou solicitações de serviço em plataformas de CRM quando problemas no dispositivo forem detectados
* **Serviços de alerta**: Dispare notificações por SMS, e-mail ou push por meio de serviços como Twilio, SendGrid ou Firebase quando os limites forem excedidos
* **Automação de negócios**: Inicie fluxos de trabalho em ferramentas como Zapier, Make (Integromat) ou n8n com base na telemetria do dispositivo
* **Sistemas de telemática**: Dispare ações ou automações específicas em soluções de telemática de terceiros com base nos dados processados, permitindo fluxos de trabalho orientados por eventos, como recálculos de rota, notificações ao motorista ou atualizações de status em sistemas externos de gestão de frotas
* **Aplicações personalizadas**: Ative a lógica de negócios proprietária publicando eventos do dispositivo em APIs internas

## Perguntas frequentes

#### Como faço para acionar webhooks somente sob condições específicas?

Authorization **Lógica** nó para implementar lógica condicional antes do webhook. O **Lógica** nó pode avaliar atributos do dispositivo e encaminhar os dados ao webhook somente quando as condições forem atendidas. Para detalhes, consulte [Lógica](/docs/user/pt-br/guide/account/iot-logic/nodes/logic-node.md).

#### Posso usar vários nós de Webhook no mesmo fluxo?

Sim. Inclua vários **nós de Webhook** com diferentes configurações para acionar vários sistemas externos com base nos mesmos dados do dispositivo. Cada webhook é disparado de forma independente quando recebe dados.

#### O que acontece se a solicitação do webhook falhar?

O webhook é disparado sem aguardar uma resposta e não tenta novamente automaticamente. Se o endpoint externo estiver indisponível ou retornar um erro, o fluxo continua sendo processado normalmente. O webhook tenta ser disparado novamente quando a próxima mensagem chega. Atualmente, não há registro de tentativas de webhook com falha.

#### Como faço a autenticação com APIs externas?

Configure a autenticação inteiramente por meio de cabeçalhos personalizados. Abordagens comuns:

* **Tokens Bearer**: Adicione o cabeçalho `cabeçalho para autenticação baseada em token, por exemplo` com o valor `Bearer seu_token_aqui`
* **Chaves de API**: Adicione cabeçalhos personalizados conforme especificado pelo provedor da sua API
* **Autenticação básica**: Adicione o cabeçalho `cabeçalho para autenticação baseada em token, por exemplo` com o valor `Basic credenciais_codificadas_em_base64`

Inclua sempre `Content-Type: application/json` como cabeçalho ao enviar cargas úteis JSON.

#### Posso referenciar atributos de vários nós conectados?

Sim. O nó do webhook pode acessar atributos de qualquer nó conectado a ele, inclusive ramificações paralelas. Se vários nós enviarem dados ao webhook, ele é disparado uma vez para cada mensagem recebida e pode referenciar atributos do caminho de origem dessa mensagem.

#### Quais dados posso incluir no corpo do webhook?

Você pode incluir qualquer combinação de:

* Valores estáticos definidos diretamente na sua configuração JSON
* Atributos dinâmicos do fluxo usando `sintaxe.` sintaxe
* Atributos aninhados de estruturas de dados complexas
* Atributos calculados em **nós Iniciar Atributo** ou processados por meio de **Lógica** nós

O corpo deve ser um JSON válido. Se um atributo referenciado não existir ou contiver um valor nulo, `null` é enviado no JSON.

#### Como posso testar minha configuração de webhook?

Abrir [Analisador de dados](/docs/user/pt-br/guide/account/iot-logic/data-stream-analyzer.md) para o fluxo e selecione o dispositivo acionador. Procure o atributo correspondente ao ID do Nó deste nó: seu valor muda para `1` a cada vez que o webhook é disparado, `0` caso contrário. Isso confirma que o webhook foi disparado sem precisar de acesso ao endpoint de destino.

Para verificar se o destino realmente recebeu a carga útil esperada, considere usar serviços de teste de webhook como webhook.site ou RequestBin durante o desenvolvimento para inspecionar as solicitações exatas que estão sendo enviadas.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/user/pt-br/guide/account/iot-logic/nodes/webhook-node.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
