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.

DirectionPortLabelWhat flows through it
OutputoutputMessage

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.

PropertyTypeDefaultDescription
Credential
credentialId
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 token
verifyToken
string "" The token set in Meta's webhook config — echoed on the GET verification (hub.verify_token). Blank accepts any (dev only).
App secret
appSecret
string "" Meta app secret — verifies the X-Hub-Signature-256 HMAC on each inbound POST (serve mode).
Webhook path
path
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 burst
rateLimitBurst
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 URL
baseUrl
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.