WhatsApp Make.com Scenarios: Cloud App and Webhooks

Make is where operations people build the automations that would otherwise need a developer: a router that sends each new WhatsApp lead to the right sheet, a scheduled run that nudges everyone with an unpaid invoice, an AI step that tags incoming messages. A WhatsApp Make integration takes one of two routes, and choosing the wrong one costs a week.

This guide covers both. First, Make's own WhatsApp Business Cloud app, which connects to Meta's platform. Then the Custom webhook and HTTP module pattern for Tenashi, which sends from a number you already use and has no app in Make's directory. Along the way: a complete example scenario, the queue and rate limits that shape it, and how to verify webhook signatures when Make can't do it for you.

Which route fits your number

If you already run a Cloud API number, or need templates and verified sending, use Make's app. If your customers message a regular WhatsApp or WhatsApp Business number and your team answers those chats, the webhook route fits. The complete guide to the WhatsApp API covers the underlying platform choice.

Make's WhatsApp Business Cloud app

Make's WhatsApp Business Cloud app covers the common Cloud API jobs: instant modules that watch for events such as incoming messages, sending messages and template messages, uploading and downloading media, registering senders, and reading or updating the business profile.

What you need, per Make's documentation, is a Meta business portfolio with a WhatsApp Business Account and a valid business number with two-step verification turned off. The standard connection lets you pick the portfolio and account inside Make without pasting a token. A legacy connection using a permanent system user token and the account ID is still supported until April 2027, so if an older scenario uses one, plan the switch.

To receive messages, add one of the app's instant modules, click Create a webhook, choose the connection and select the events to watch. Make handles registration with Meta for you.

The platform rules come along unchanged. Free-form messages only go through within 24 hours of the customer's last message; outside that, use the template module with an approved template. The 24-hour window explained has the details that catch people out, such as which messages reopen it.

The Tenashi route: Custom webhook in, HTTP module out

Tenashi has no Make app. You don't need one, because Tenashi POSTs signed JSON to any HTTPS URL and Make webhook URLs work as they are.

Receiving: Webhooks, Custom webhook

1. Add the Webhooks app's Custom webhook as the first module and create a new webhook. Under advanced settings, turn on Get request headers so the signature headers are available for mapping.
2. Copy the URL. In Tenashi, open Settings, API and webhooks, add it as an endpoint and subscribe to message.received.
3. Click Send test in Tenashi, or wait for a real message, so Make learns the data structure. If you later need fields that weren't in the sample, open the module and use Detect new values.

Each event arrives as one bundle. The useful fields live under data.message: text, sender.phone, sender.name, chat.type (dm or group), conversationId, and number for the line it came in on. The event's top-level id is unique per event.

Two Make behaviours matter here. Without a Webhook response module, Make answers 200 with the body Accepted as soon as the request is queued, which comfortably meets Tenashi's requirement of a 2xx within 10 seconds. And each webhook has its own queue: Make processes up to 300 incoming requests per 10 seconds and returns 429 above that, and a full queue answers 400. Tenashi retries failed deliveries 8 more times over about a day, so a brief overload loses nothing, but an endpoint that keeps refusing events (a full queue, a deleted webhook) is disabled after 3 days of failures.

Delivery is at least once, so design for repeats. Use search-then-create steps in the destination apps, or keep a data store of processed event IDs and filter on it.

Sending: HTTP, Make a request

1. Add the HTTP app's Make a request module.
2. Authentication type: API key. Create a keychain with Key Bearer tk_live_... (Make wants the prefix included in the value), placement in the header, and parameter name Authorization. Keeping the key in a keychain, not a header field, is what Make's docs recommend.
3. URL https://usetenashi.com/api/v1/messages, method POST.
4. Headers: one header, Idempotency-Key, mapped to something unique such as the event ID with a suffix.
5. Body content type application/JSON. For the body input method, prefer Data structure over JSON string: Make then builds and escapes the JSON for you, so a customer name containing a quote can't break the request.
6. Parse response: Yes. Return error if HTTP request fails: Yes in most scenarios, so a 4xx or 5xx stops the bundle and your error handler sees it.

If you do use JSON string, map only values that can't contain quotes, like IDs. Here module 1 is the Custom webhook:

{
  "conversationId": "{{1.data.message.conversationId}}",
  "text": "Thanks for your message. Here is our current price list."
}

A good response is 202 with the message queued. It leaves the number 4 to 12 seconds later and shows up in your team's inbox like any other reply. Replying by conversationId posts into the same chat, whether a DM or a group.

Example scenario: route WhatsApp leads and reply with a price list

This scenario handles the most common small-business case: people ask for prices on WhatsApp, and the team wants every request logged and answered fast.

1. Webhooks, Custom webhook. Tenashi message.received events.
2. Router with two routes.
3. Route A, filter: data.message.chat.type equals dm and data.message.text contains price (case insensitive).
   • Google Sheets, Add a row: date, sender.name, sender.phone, text.
   • HTTP, Make a request: reply with conversationId, a short personalised text, and a media object whose url points at your price list PDF. Idempotency-Key: the event ID plus -price.
4. Route B, filter: chat.type equals group.
   • Slack, Create a message: post the group name and text to a channel, so someone on the team picks it up in the shared inbox.
5. Filter after the HTTP module: if the status code is 429 or 422, notify a person instead of retrying. For this module, set Return error if HTTP request fails to No so the response reaches the filter.

Those two codes are ban protection. new_chat_limit means the number has opened 50 new chats through the API today (people who never wrote to you; replies like the one above don't count). send_blocked means the exact same text went to 5 chats within 10 minutes. Personalising the text with the sender's name avoids the second one.

A scheduled variant works the same way in reverse: a Google Sheets search for rows due tomorrow, an iterator, then the HTTP module per row. The appointment reminders guide covers timing and wording for that pattern.

Verifying Tenashi's signature before Make

Anyone who learns a Custom webhook URL can post to it. Treat the URL as a secret, and if it leaks, create a new webhook and update Tenashi. When you need cryptographic proof that an event came from Tenashi, check the X-Tenashi-Signature header, which is a hex HMAC-SHA256 of the timestamp, a dot and the raw body.

Make's Custom webhook parses the body before your modules see it, so the dependable approach is a tiny verifier in front of Make. This Cloudflare Worker checks the signature and timestamp and forwards the untouched body:

// worker.js: check Tenashi's signature, then forward the event to Make
export default {
  async fetch(request, env) {
    if (request.method !== 'POST') return new Response('Method not allowed', { status: 405 });

    const raw = await request.text();
    const timestamp = request.headers.get('x-tenashi-timestamp') || '';
    const signature = (request.headers.get('x-tenashi-signature') || '').replace(/^v1=/, '');
    const fresh = Math.abs(Date.now() / 1000 - Number(timestamp)) < 300;

    const enc = new TextEncoder();
    const key = await crypto.subtle.importKey(
      'raw', enc.encode(env.TENASHI_WEBHOOK_SECRET),
      { name: 'HMAC', hash: 'SHA-256' }, false, ['verify'],
    );
    const sigBytes = new Uint8Array((signature.match(/../g) || []).map((h) => parseInt(h, 16)));
    const valid = await crypto.subtle.verify('HMAC', key, sigBytes, enc.encode(`${timestamp}.${raw}`));

    if (!fresh || !valid) return new Response('Bad signature', { status: 401 });

    const res = await fetch(env.MAKE_WEBHOOK_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: raw,
    });
    // Make answers 200 once the event is queued; anything else makes Tenashi retry.
    return new Response(null, { status: res.ok ? 200 : 502 });
  },
};

Store TENASHI_WEBHOOK_SECRET and MAKE_WEBHOOK_URL as Worker secrets, register the Worker's URL in Tenashi instead of Make's, and keep Make's URL private. crypto.subtle.verify compares in constant time, and the same logic ports to any runtime with Web Crypto.

Where Tenashi fits

Make is excellent at moving data between apps, and the scenario above can log, route and auto-answer. What it can't do is give a team one place to read and answer the conversations those automations start. With Make's WhatsApp Business Cloud app, the number also has to live on Meta's platform, with templates and per-message pricing.

Tenashi links your existing WhatsApp or WhatsApp Business number by QR scan and puts every DM and group in a shared inbox, with a CRM, tickets and follow-ups under each chat. Make listens through webhooks and sends through the HTTP module, and everything it sends appears in the threads your team works. Limits worth knowing: no Make app, no templates or buttons, and paced sends that lower ban risk without removing it. Plans start from $18/mo.

Read the API docs · Get started

FAQ

Does Make have a WhatsApp integration?

Yes. Make's WhatsApp Business Cloud app sends messages and templates, handles media and watches events through instant webhook modules, for numbers registered on Meta's WhatsApp Business Platform. Its standard connection picks your business portfolio and WhatsApp Business Account inside Make. Other APIs, like Tenashi's, connect through the Webhooks and HTTP apps.

Is there a Tenashi app on Make?

No. Use the Webhooks app's Custom webhook to receive Tenashi events and the HTTP app's Make a request module to send, with an API key keychain holding Bearer plus your key in the Authorization header. Make's webhook URLs work in Tenashi's settings without changes, and Tenashi's Send test button gives Make a sample event.

Why didn't my scenario run when a WhatsApp message arrived?

Check that the scenario is switched on and the webhook is the one registered in Tenashi or Meta. In Tenashi's settings, the endpoint's recent deliveries show the status Make returned. A 400 means the webhook queue is full, a 429 means too many requests in 10 seconds, and a disabled endpoint needs re-enabling after you fix it.

Can Make send a WhatsApp message to a group?

Through Tenashi, yes: send with the group's conversationId, taken from any webhook or from the conversations endpoint filtered to groups. Through Meta's platform, only groups created with the Groups API, which requires an Official Business Account and allows 8 participants. Groups your number is already in are out of reach of Meta's API.

How do I avoid duplicate replies in Make?

Send an Idempotency-Key header built from the event ID on every reply, so a repeated event within 24 hours returns the first response and sends nothing. For the logging side, use search-then-create in Sheets or your CRM, or keep processed event IDs in a Make data store and filter them out.

---

Two modules in, two modules out, and a router in between covers most of what teams want from WhatsApp and Make. If you are comparing tools, see the Zapier version and the n8n version, and to connect your own number, read the Tenashi API docs.