You already have the workflow. A form fills, a payment clears, six steps run. The step you cannot find is the one that puts a WhatsApp message in front of a human, from the number that human already has saved.
Can you send WhatsApp messages from n8n, Make, or Zapier without the Meta Cloud API?
Yes. You send it as a plain HTTPS POST to an own-number WhatsApp API, which drives your existing WhatsApp account through WhatsApp Web or a hosted gateway rather than Meta's Cloud API. No business verification, no template approval, no Meta-issued number.
Be clear on what that looks like in the builder, because this is where guides mislead people. There is no Blueticks app in Zapier, no Blueticks module in Make, and no n8n WhatsApp node for Blueticks, built-in or community. Search the picker and you will find nothing. What you use instead is the generic HTTP Request node (n8n), the HTTP app (Make), or Webhooks by Zapier, pointed at https://api.blueticks.co/v1/... with a bt_live_ API key in an Authorization header. That is the whole integration, it works identically on all three platforms, and it is why the rest of this article is about fields rather than apps.
Honest counterpoint up front: if your job is template broadcast to tens of thousands of numbers, or a shared inbox with six agents, read the BSP section before building anything.
What do you need before you build the workflow?
Four things, and only one takes real setup. This is a checklist, not a tutorial, and each item links to where it is actually taught.
- A connected WhatsApp number. Your existing account, linked once through the browser extension or the always-on cloud gateway. The gateway is the one that keeps sending with your laptop shut.
- A
bt_live_API key. What it unlocks and where it belongs are in the own-number REST API guide. - An account on one of the three platforms. n8n Cloud or self-hosted, Make, or Zapier.
- A publicly reachable callback URL, only if you want replies and delivery status back.
One number to plan around: on a free plan the /v1 API allows 5 requests per 6-hour window, shared across REST and MCP. An active subscription lifts it. It will stop a test loop dead.
Read this before you build a loop. A workflow platform makes an unattended blaster a four-node job. One send per row of a 5,000-row sheet, back to back, is the most reliable way to get your number restricted. Batching, delays and caps are covered below, and they are build instructions, not disclaimers.
How do you send a WhatsApp message from n8n with the HTTP Request node?
An n8n WhatsApp send is one node. Drop in HTTP Request, set Method to POST, put the recipient in the URL path, attach a header credential carrying your key, and send a JSON body with a type discriminator. No installation, because the node ships with n8n.
Every field, using n8n's own HTTP Request node labels:
| Field | Value |
|---|---|
| Method | POST |
| URL | https://api.blueticks.co/v1/scheduled-messages/+5511987654321 |
| Authentication | Generic Credential Type |
| Generic Auth Type | Header Auth |
| Header credential → Name | Authorization |
| Header credential → Value | Bearer bt_live_YOUR_KEY_HERE |
| Send Body | on |
| Body Content Type | JSON |
| Specify Body | Using JSON |
Two details trip people up. The recipient lives in the path, not in a to body field: the endpoint is POST /v1/scheduled-messages/{chatId}, and the segment takes E.164 with a leading plus (+5511987654321, +4915123456789) or a WhatsApp chat id (5511987654321@c.us, or ...@g.us for a group). And the Authentication dropdown offers Predefined Credential Type first; there is no predefined entry here, so pick Generic Credential Type → Header auth.
The body is flat, with no nested media or poll objects, and type is required even for plain text. To defer rather than fire now, add sendAt: camelCase, ISO 8601 with an offset, at least 10 seconds ahead and at most 365 days out.
{
"type": "text",
"text": "Reminder: your appointment is tomorrow at 14:00.",
"sendAt": "2026-08-08T09:00:00+02:00"
}
Per the endpoint's published response schema, the fields you branch on are id, waMessageKey (the message key object, not key, and null until the engine dispatches), status, and the confirmedAt / receivedAt / readAt / failedAt timestamps. The status enum runs pending → confirmed → received → read → played, with failed terminal: confirmed means WhatsApp accepted it, received is the second grey tick. For the same call in cURL, Python or Node, see the API first-send guide.
Mapping a trigger's output into the request body in n8n
This is where a working whatsapp n8n integration usually stalls: the send works with a hardcoded string and breaks the moment real trigger data arrives. n8n uses {{ }} delimiters, $json for the current item, and $('Node Name') for any earlier node.
Say a Webhook node named New Order receives {"customer": {"phone": "+4915123456789", "name": "Lena"}, "order_id": 4417}. In expression mode the URL becomes https://api.blueticks.co/v1/scheduled-messages/{{ $json.customer.phone }}, and the body references the named node so it survives extra steps between trigger and send:
{
"type": "text",
"text": "Hi {{ $('New Order').item.json.customer.name }}, order #{{ $('New Order').item.json.order_id }} is confirmed."
}
$json is documented as shorthand for $input.item.json, so it points at whatever the immediately preceding node handed you. Insert a Set or Filter node between trigger and send and $json.customer.phone silently becomes undefined, and the request 400s on the path parameter. The named form keeps working, and n8n's page on referencing previous nodes adds .first() and .last() for ambiguous item pairing. Two more traps: numbers without the leading + fail the E.164 check, and an expression resolving to an empty string leaves a trailing slash that reads as a missing recipient.
Why your n8n webhook never fires when you self-host
Self-hosted n8n derives its webhook URL from environment variables, and behind Docker, NAT or a reverse proxy the URL printed in the editor is not the URL the outside world can reach. Nothing errors. The callback simply never arrives.
The mechanism is explicit in the docs: n8n "creates the webhook URL by combining N8N_PROTOCOL, N8N_HOST and N8N_PORT. If n8n runs behind a reverse proxy, that won't work." Set it manually with N8N_WEBHOOK_URL, which n8n's reverse-proxy configuration page notes replaces the deprecated WEBHOOK_URL (still accepted, logs a deprecation warning), and set N8N_PROXY_HOPS to the number of proxies in front of you.
Diagnose in order. Copy the URL n8n shows and curl it from outside your network; a timeout or a private address means the URL is the problem, not the workflow. Then confirm you are on the Production URL: per the Webhook node docs, the Test URL only listens while you are actively watching for a test event, while the production URL registers on publish and its runs land in the Executions tab. The ways out are a tunnel for development, a correctly configured reverse proxy, or n8n Cloud.
How do you send a WhatsApp message from Make.com?
Add the HTTP app's Make a request module, or Make an API Key Auth request to store the key as a reusable connection. Same POST, same path-based recipient, same flat body.
To send whatsapp from make.com, set URL to https://api.blueticks.co/v1/scheduled-messages/+5511987654321, Method to POST, one Headers row of Authorization / Bearer bt_live_YOUR_KEY_HERE, Body type Raw, and Content type JSON (application/json).
Make's mapping is the second of three dialects here. Rather than typing an expression, you click the field and pick the item from the mapping panel, which inserts a token prefixed by the source module's id. You type the JSON scaffolding by hand in Request content and drop tokens into the string positions, like "text": "Hi {{2.name}}, your booking on {{2.date}} is confirmed.". That numeric prefix matters when you clone a scenario: cloned modules get new ids, so a mapping that looks fine can point at the wrong module.
What Make's blocking HTTP module means for your scenario's operation count
Make meters per module run, and the HTTP module blocks while waiting for the response. A scenario iterating 500 rows and sending one message each does not cost one unit. It costs at least 500, plus the iterator's own run, and it holds an execution slot for all 500 round trips.
Make's help centre defines an operation as a single module run to process data or check for new data, with the count depending on how many bundles the module processes; their worked example is a Send-an-email module sending 5 emails costing 5 operations. Your HTTP module behaves the same. As of August 2026, Make's pricing page expresses plan allowances in credits, most actions consuming one each. Treat the vocabulary as movable and the model as stable: one module run, one billable unit. Read the live page, not any number in a blog post.
The blocking part has a second cost that never reaches an invoice. At 800ms per send, 500 sends is roughly seven minutes of one scenario holding its slot, so on a tighter schedule runs overlap or queue. Batch across runs instead.
How do you send a WhatsApp message from Zapier?
Use the Webhooks by Zapier app, action event POST for a normal JSON send, or Custom Request when you need control over the raw body. Zapier's help docs list four send actions: GET, POST, PUT and Custom Request.
For a whatsapp zapier integration, the POST action takes URL (https://api.blueticks.co/v1/scheduled-messages/+919876543210, phone inserted through the field picker), Payload Type set to JSON rather than Form or XML, Data as key/value rows (type → text, text → your message), and Headers carrying Authorization / Bearer bt_live_YOUR_KEY_HERE.
The field picker is the third mapping dialect: click into a field, choose the source step, and Zapier inserts a token. No expression syntax, but no inline string manipulation either, so anything needing a transform before it hits the path is a Formatter step in front of the webhook. Body handling differs by action: POST builds key/value pairs, while Custom Request sends raw JSON from the Data field exactly as entered, unparsed.
What a fan-out costs you on Zapier's per-task pricing
Zapier bills per task, and a task is any successful action that runs. A Zap sending to 500 recipients costs roughly 500 tasks every time it runs, scaling linearly in a way a self-hosted n8n instance does not.
Two parts of that accounting are free, and getting them right changes the estimate. Per Zapier's plan and pricing FAQs, "Zap triggers never use tasks", and Filter, Paths, Formatter, Delay and Looping steps do not consume tasks either. Only successful actions count. So the 500-recipient fan-out is: trigger free, Looping step free, 500 successful POSTs at 500 tasks. Run it weekly and one workflow is 2,000+ tasks a month.
Zapier's pricing page, read on 7 August 2026, puts the free plan at 100 tasks per month and starts paid tiers at 750, which makes a single 500-recipient send five times the entire free allowance. Tiers move, so check the live page.
How do you get replies and delivery status back INTO your workflow?
Two directions, and they are not symmetrical. Inbound (your workflow calling the API) is everything above. Outbound (a WhatsApp event pushing into your workflow) means giving the sender a URL and naming the events to push. Registration and signature verification are covered in the webhooks and auto-reply guide; this section is only about which node catches the event.
In n8n, add a Webhook node, set Method to POST, publish the workflow, copy the Production URL, and branch with a Switch or IF node on the event field. There is no first-party n8n guide, so this is the build-it-yourself path, and reachability matters more here than anywhere else.
Make and Zapier are easier, because Blueticks ships first-party outbound guides for both. In Zapier, start a Zap with Webhooks by Zapier → Catch Hook and copy the generated URL; in Make, add a Custom webhook module and copy its address. Paste that URL into the Webhooks tab of the Blueticks API page. Screenshot walkthroughs live in-product at the Zapier webhook guide and the Make webhook guide. To be exact: outbound-only guides for receiving events, not native apps, and they do not send anything.
Watch the vocabulary here, because it trips people: the webhook event names are a different set from the status values you polled earlier, and they do not line up one-to-one. The events are message.queued, message.sending, message.delivered, message.failed and message.read. Internally they are driven off the message's own status, and the mapping is not the one the names suggest — message.delivered fires when the message reaches confirmed, and its payload carries status: "confirmed", not "delivered". There is no message.received event at all. So a Switch node keyed on the status expecting received will simply never fire — in fact received never appears in any webhook payload at all. Branch on the event name, which arrives as type at the top level of the body; the message itself sits under data, so the status you would otherwise have tested is data.status. Retries are the subtle part: every platform will happily re-fire a step, and a request-level Idempotency-Key header exists for exactly that, worked out in the automation API guide. The platform-specific half is only that each retry must reuse the same key rather than minting a fresh one. If you wanted the agent-driven path instead of a workflow builder, that is the MCP route.
How do you send to a list without getting your number restricted?
Batch it, delay between sends, cap the run, and stop on the first error instead of retrying into a wall. Nobody can promise a number will not be restricted, and anyone who does is selling something. What you control is the shape of the workflow.
The concrete build, in n8n terms, with equivalents on all three:
- Batch. Put a Loop Over Items node (in the picker as Loop Over Items, formerly Split In Batches) in front of the HTTP Request and set Batch Size small. Thirty is a starting point, not a magic number.
- Delay. Add a Wait node inside the loop, Resume set to
After Time Interval, then set Wait Amount and Wait Unit. Seconds, not milliseconds. Uniform intervals are themselves a pattern, so vary it if your data allows. - Cap the run. Limit how many messages one execution can send and let tomorrow's take the rest. A cap is the only control that survives a bad input file.
- Stop on error. Leave "Retry On Fail" off for the send node and route the error output somewhere you will look. A retry storm against a struggling connection turns one failure into fifty.
On Make the same shape is an Iterator plus a Sleep module; on Zapier it is Looping by Zapier plus Delay, neither of which consumes tasks, so pacing there is free. If your list starts in a spreadsheet, the bulk-from-spreadsheet guide covers the data side. And one sentence on consent, because it is not ours to carry: collecting opt-in from every recipient is the sender's responsibility. Be clear-eyed about what that does and does not buy you — WhatsApp's own position is unconditional: its products are not intended for bulk or automated messaging, both of which have always been a violation of its Terms of Service. Opt-in lowers the chance recipients report you; it does not grant permission.
When should you use a BSP instead of any of this?
Two cases, and neither is close. If you are broadcasting approved templates to tens of thousands of numbers, use a Business Solution Provider on Meta's Cloud API. That is what the platform is engineered for: high daily throughput ceilings, a quality-rating system, and messaging limits that scale up as you behave well. An own-number API runs at personal-account scale, and no workflow design changes that.
The second case is a shared inbox. If four or six agents need to work the same WhatsApp number, with assignment, internal notes and handover, you want a proper BSP-backed agent desk. An own-number API gives your code a way to send and receive. It does not give six humans a queue to work from.
There are real costs on the other side, which is why the own-number path exists at all: business verification, template approval before you can message outside the 24-hour service window, and per-message billing on Meta's published pricing. But in either of those two situations the HTTP Request node is the wrong tool, and you will find out in month two rather than week one. The BSP alternatives comparison is where to start that evaluation.
What does Blueticks add once your workflow is running?
Look at what the workflow is not doing. Your HTTP Request node fires and returns. There is no send queue behind it, so a burst goes out as a burst. No backoff except the retry logic you hand-built. No delivery state beyond what you poll for or catch in a webhook you wired yourself. No pacing except the Wait node you remembered to add, and no record of what went out except execution history that rolls off.
Blueticks is what the HTTP node is calling. The queue, the connected WhatsApp session, the gateway that keeps sending with your laptop closed, the delivery lifecycle that produces confirmed / received / read, the scheduling window that lets sendAt mean something 90 days out: that is the part you would otherwise build and then maintain.
Which is why this integration is one node instead of a subsystem. The workflow platform decides when and to whom, using triggers you already have wired. The API owns sending it reliably and telling you what happened. Point your HTTP Request node at a bt_live_ key from a free account and the send side collapses into one POST.
FAQ
Is there a Blueticks n8n node?
No. There is no n8n WhatsApp node for Blueticks, built-in or community, and no Zapier app or Make module either. You use the generic HTTP Request node, the HTTP app's Make a request module, or Webhooks by Zapier, pointed at https://api.blueticks.co/v1/ with your key in an Authorization header.
Does this use the WhatsApp Cloud API? No. It sends through your own existing WhatsApp account, over WhatsApp Web or a hosted gateway. That is why there is no business verification, no template approval and no Meta-issued number, and also why it runs at personal-account scale.
Will my number get banned? Nobody can guarantee it will not, and treat any guarantee as a red flag. WhatsApp states plainly that its products are not intended for bulk or automated messaging, both of which have always been a violation of its Terms of Service — that is unconditional, not something opt-in exempts you from, and restriction is a real outcome. Batch, delay, cap the run, and only message people who opted in.
Can I send images and PDFs from a workflow?
Yes. Set "type": "media" and supply mediaUrl (https only) or mediaBase64, with text doubling as the caption. There is no separate caption field. Details are in the image and document guide.
What does a 500-recipient send cost on Zapier versus self-hosted n8n? On Zapier, roughly 500 tasks, since successful actions count while triggers, filters and looping steps do not. Self-hosted n8n costs compute, with no per-execution fee. Make sits between them at one billable unit per module run. Figures live on Zapier's pricing page and Make's pricing page.
Can I schedule a message instead of sending it now?
Yes. Add sendAt as an ISO 8601 timestamp with an offset, at least 10 seconds ahead and no more than 365 days out. The scheduling contract, including editing and cancelling a queued message, is in the own-number REST API guide.
Which platform should I pick for whatsapp automation n8n workflows specifically? If you are already on one, stay there, because the integration is identical on all three. If you are choosing fresh and expect fan-outs, self-hosted n8n is the only one where sending to 500 people does not multiply the bill by 500.
