WhatsApp Trigger
input.whatsapp Input v0.1.0 Starts the workflow when a WhatsApp message arrives (Meta Cloud API webhook). Answers the GET verification challenge and normalizes each inbound message to a flat { from, type, text, mediaId, interactiveReply, contactName, … } shape.
Finding it in the library
Search the builder's node library for WhatsApp Trigger (it lives under Input). A single click opens the in-editor docs panel shown here — description, ports, and every property, without leaving the canvas. Double-click (or drag) to add it to the workflow.
Library capture pending — regenerate with npm run shots:nodes.
Wired up in the builder
WhatsApp Trigger in a real, runnable flow — captured live from the Studio editor, exactly as it looks on your canvas. This is the same workflow used for the example input & output below.
Canvas capture pending — regenerate with npm run shots:nodes.
How it’s configured
The node’s Configure panel as it opens in the builder when you select the step — every setting laid out with real values. Click any field to edit it.
Config capture pending — regenerate with npm run shots:nodes. See the full property reference below.
Ports
This is a trigger — it starts runs and takes no input wire.
Ports are the node’s contract with its neighbours. In the editor a port label renders bold when wired and italic when optional; ◈ ports accept attachment carriers rather than data wires.
| Direction | Port | Label | What flows through it |
|---|---|---|---|
| Output | output | Message |
How data flows through it
As a trigger, WhatsApp Trigger starts runs — it takes no input wire. What it emits is
the request wrapper: the event’s body becomes the payload, and the wrapper
carries the event metadata around it (for an HTTP-style trigger that’s
headers.*, request.method, request.path and
query). Downstream nodes consume the content — the wrapper is unwrapped
at each node boundary, and expression roots like {{ headers.x }} still
resolve against the wrapper when you need the metadata. See
Runs & run data for the envelope model.
Expressions in the config
String-typed properties accept {{ }} expressions evaluated against the
incoming item at run time — e.g. {{ $json.customer.email }}. On this node
that’s verifyToken, appSecret, path, baseUrl. JSON- and code-typed fields never interpolate — they are passed through literally.
Build it with AI
Every node in this reference is reachable through Flowdrome’s
AI Copilot and the
MCP tools — say what you want, and the graph surgery
happens server-side. Node types resolve fuzzily, so the catalog label
(WhatsApp Trigger) works as well as the exact type id (input.whatsapp).
In the Copilot panel (or any connected AI):
create a workflow that starts with whatsapp trigger and logs the result As a step in a create_chain_workflow call:
{"type":"WhatsApp Trigger","config":{}} Raw MCP call — add this node to a workflow with add_node
curl -s -X POST http://localhost:48170/mcp -H "content-type: application/json" -d '{ "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "add_node", "arguments": { "workflowId": "<id>", "type": "WhatsApp Trigger" } } }' Example input & output
Captured from a real test run of the workflow above — this is what you see in the run data panel after pressing Test workflow.
Input — what the node received
{
"entry": [
{
"changes": [
{
"value": {
"messages": [
{
"from": "15551230000",
"id": "wamid.in",
"type": "text",
"text": {
"body": "hi wa"
}
}
]
}
}
]
}
]
} Output — what the node produced
{
"from": "15551230000",
"id": "wamid.in",
"timestamp": "",
"type": "text",
"text": "hi wa",
"phoneNumberId": "",
"message": {
"from": "15551230000",
"id": "wamid.in",
"type": "text",
"text": {
"body": "hi wa"
}
}
} Property reference
Every setting, with its type and default — the same fields shown configured in the panel above.
| Property | Type | Default | Description |
|---|---|---|---|
CredentialcredentialId | credential | "" | Use a stored credential for this connection — its fields are filled in at run start. Pick "None" to enter the connection details manually. accepts credential templates: whatsapp |
Verify tokenverifyToken | string | "" | The token set in Meta's webhook config — echoed on the GET verification (hub.verify_token). Blank accepts any (dev only). |
App secretappSecret | string | "" | Meta app secret — verifies the X-Hub-Signature-256 HMAC on each inbound POST (serve mode). |
Webhook pathpath | string | "/whatsapp/webhook" | The local route Meta POSTs message webhooks to (and GETs to verify). |
Max body (bytes)maxBodyBytes | int | 1048576 | Largest request body this trigger accepts — bigger requests are rejected with 413 before the workflow runs. 0 = unlimited at the trigger (the app-wide FLOWDROME_MAX_BODY_BYTES ceiling, default 32 MB, still applies). |
Rate limit (req/s)rateLimitRps | double | 0 | Per-client-IP sustained request rate for this trigger. 0 = no rate limit (the default). For internet-exposed apps, prefer rate limiting at a fronting reverse proxy (docs/ingress-guards-design.md). |
Rate limit burstrateLimitBurst | int | 0 | How many requests a client may send back-to-back before the per-second rate applies. 0 = automatic (2× the rate). Shown when (showIf === undefined || showIf(c)) && Number(rateLimitRps ?? 0) > 0 |
Base URLbaseUrl | string | "https://graph.facebook.com" | Graph API base URL (override for testing). |
Related nodes
The rest of the Input group — the same folder you’d scan in the editor’s library.
This page is generated from the node registry by gen-node-docs.mjs on every
site build — ports, properties, defaults and visibility rules cannot drift from the code.
The screenshots and example data are captured from a live Flowdrome by
npm run shots:nodes and npm run gen:examples.