API de WhatsApp no Make: receber, processar e responder

Não tem app da D-API no Make, e tudo bem

Vale deixar claro antes de começar: a D-API não publica um app no catálogo do Make. A ligação é feita com peças que o próprio Make oferece para qualquer serviço com API REST. Na ida, o app HTTP chama os endpoints da D-API. Na volta, o app Webhooks gera uma URL que a D-API chama sempre que algo acontece no número conectado.

Essa é a mesma lógica de qualquer API de WhatsApp integrada via HTTP. A vantagem de montar assim é que você enxerga cada campo que vai e volta, sem depender de um conector que esconde o payload. A desvantagem é que o mapeamento é manual, e é exatamente isso que este guia cobre.

O cenário que vamos montar

Um atendimento de primeiro nível, com quatro módulos em sequência:

1. Webhooks, Custom webhook: recebe o evento messages.received da D-API.
2. Filtro: descarta mensagens enviadas pelo próprio número e mensagens de grupo.
3. Processamento: um Router que decide a resposta pelo conteúdo, ou uma consulta ao seu CRM, ou um módulo de IA.
4. HTTP, Make a request: chama /api/v1/messages/send/text com a resposta.

Passo 1: criar o Custom webhook e apontar a D-API para ele

No editor do cenário, adicione o app Webhooks e escolha Custom webhook como gatilho. Clique em adicionar, dê um nome ao webhook e copie a URL que o Make gera. O módulo fica esperando a primeira requisição para aprender o formato dos dados.

Agora diga à D-API para mandar os eventos de mensagem recebida para essa URL:

curl -X POST https://api.d-api.cloud/api/v1/sessions/minha-sessao/webhook-config \
  -H "Authorization: SUA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "type": "single",
    "events": {
      "messages.received": { "enabled": true, "webhookUrl": "https://hook.make.com/SUA_URL" }
    }
  }'

Com o módulo em modo de escuta, mande uma mensagem de outro celular para o número conectado. O Make captura o payload e passa a mostrar os campos para mapear: event, sessionId e, dentro de data, os campos message, fromMe, is_group, from_name e from.jid. Se depois você precisar de um campo que não apareceu, use a opção de redeterminar a estrutura e envie outra mensagem de teste.

Passo 2: filtrar antes de gastar operação

Clique na linha entre o webhook e o próximo módulo e crie um filtro com três condições, todas obrigatórias:

• event igual a messages.received
• data.fromMe igual a false, para não responder o que o próprio número enviou de outro aparelho
• data.is_group igual a false, a menos que o bot deva falar em grupos

Esse filtro é o que impede o cenário de entrar em loop e de consumir cota do plano Make com eventos que não interessam. Se você só configurou o evento de mensagem recebida, a primeira condição é redundante, mas protege o cenário caso alguém ative outros eventos na mesma URL depois.

Passo 3: decidir a resposta

Aqui entra a regra do seu negócio. Três formas comuns, da mais simples para a mais flexível:

• Router com filtros por palavra: uma rota para "boleto", outra para "horário", uma rota padrão que avisa que um atendente vai responder.
• Consulta a um sistema: um módulo busca o cliente pelo telefone no CRM ou na planilha e monta a mensagem com o status do pedido.
• Módulo de IA: o texto de data.message vai para um modelo que gera a resposta. O desenho desse tipo de bot está em chatbot de WhatsApp com IA.

Passo 4: responder com HTTP Make a request

Adicione o app HTTP, módulo Make a request, e preencha assim:

No conteúdo do corpo, mapeie os campos do webhook. O from.jid chega no formato [email protected], então a função replace do Make tira o sufixo e deixa só o número. O número 1 abaixo é o id do módulo de webhook no seu cenário:

{
  "sessionId": "{{1.sessionId}}",
  "to": "{{replace(1.data.from.jid; "@s.whatsapp.net"; "")}}",
  "text": "Oi, {{1.data.from_name}}! Recebemos sua mensagem e já vamos te responder."
}

Usar o sessionId que veio no evento, em vez de fixar o nome da conexão, deixa o mesmo cenário servir vários números: basta apontar o webhook de cada conexão para a mesma URL. Isso é útil para quem opera vários números de WhatsApp com a mesma lógica.

Erros, consumo e quando o n8n faz mais sentido

Adicione uma rota de tratamento de erro no módulo HTTP. Quando a D-API recusa um envio, ela responde com success: false, uma mensagem em error e o statusCode. Registrar esses casos num Data store ou numa planilha evita descobrir o problema pelo cliente que ficou sem resposta.

Do lado da entrega, a D-API reenvia o webhook até 7 vezes com espera crescente se a URL do Make não responder. O custo que cresce é o do Make, porque cada módulo executado conta na cota do plano. Na D-API a cobrança é por conexão, não por mensagem, como mostra a página de planos.

Se o volume subir ou o time preferir algo self-hosted, o n8n tem um node nativo da D-API para as ações de envio, o que dispensa montar o HTTP na mão. Para outros desenhos de fluxo, veja a página de API de WhatsApp para automação e o guia de webhook de WhatsApp, que detalha os eventos disponíveis.