WhatsApp API on Make: receive, process and reply

There is no D-API app on Make, and that is fine

Worth making clear before you start: D-API does not publish an app in the Make catalog. The connection uses building blocks Make offers for any service with a REST API. Outbound, the HTTP app calls the D-API endpoints. Inbound, the Webhooks app generates a URL that D-API calls whenever something happens on the connected number.

This is the same logic as any WhatsApp API integrated over HTTP. The upside of building it this way is that you see every field going in and out, without depending on a connector that hides the payload. The downside is that mapping is manual, and that is exactly what this guide covers.

The scenario we will build

A first-line support flow, with four modules in sequence:

1. Webhooks, Custom webhook: receives the messages.received event from D-API.
2. Filter: drops messages sent by the number itself and group messages.
3. Processing: a Router that picks the reply based on content, a lookup in your CRM, or an AI module.
4. HTTP, Make a request: calls /api/v1/messages/send/text with the reply.

Step 1: create the Custom webhook and point D-API to it

In the scenario editor, add the Webhooks app and choose Custom webhook as the trigger. Click add, name the webhook and copy the URL Make generates. The module waits for the first request to learn the data structure.

Now tell D-API to send incoming message events to that URL:

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

With the module listening, send a message from another phone to the connected number. Make captures the payload and shows the fields to map: event, sessionId and, inside data, the fields message, fromMe, is_group, from_name and from.jid. If you later need a field that did not show up, use the redetermine data structure option and send another test message.

Step 2: filter before spending operations

Click the link between the webhook and the next module and create a filter with three required conditions:

• event equal to messages.received
• data.fromMe equal to false, so you do not reply to what the number itself sent from another device
• data.is_group equal to false, unless the bot should talk in groups

This filter keeps the scenario from looping and from eating your Make quota with events you do not care about. If you only configured the incoming message event, the first condition is redundant, but it protects the scenario in case someone enables other events on the same URL later.

Step 3: decide the reply

This is where your business rules come in. Three common approaches, from simplest to most flexible:

• Router with keyword filters: one route for "invoice", another for "opening hours", and a default route saying an agent will reply.
• System lookup: a module finds the customer by phone number in your CRM or spreadsheet and builds the message with the order status.
• AI module: the text in data.message goes to a model that writes the reply. The design of this kind of bot is covered in WhatsApp AI chatbot.

Step 4: reply with HTTP Make a request

Add the HTTP app, Make a request module, and fill it in like this:

In the request content, map the webhook fields. The from.jid arrives as [email protected], so Make’s replace function strips the suffix and leaves just the number. The number 1 below is the ID of the webhook module in your scenario:

{
  "sessionId": "{{1.sessionId}}",
  "to": "{{replace(1.data.from.jid; "@s.whatsapp.net"; "")}}",
  "text": "Hi {{1.data.from_name}}! We got your message and will get back to you shortly."
}

Using the sessionId from the event, instead of hardcoding the connection name, lets the same scenario serve several numbers: just point each connection’s webhook to the same URL. That is useful if you run multiple WhatsApp numbers with the same logic.

Errors, usage and when n8n makes more sense

Add an error handler route on the HTTP module. When D-API rejects a send, it responds with success: false, a message in error and the statusCode. Logging those cases in a Data store or a spreadsheet saves you from finding out through a customer who never got a reply.

On the delivery side, D-API retries the webhook up to 7 times with exponential backoff if the Make URL does not respond. The cost that grows is Make’s, because every module run counts against the plan quota. D-API charges per connection, not per message, as shown on the pricing page.

If volume grows or the team prefers something self-hosted, n8n has a native D-API node for send actions, so you do not have to build the HTTP call by hand. For other flow designs, see WhatsApp API for automation and the WhatsApp webhooks guide, which details the available events.