n8n WhatsApp Order Intake: Authenticate Senders, Log Every Order

A vendor messages your operations line on WhatsApp with an order. Is it really them, or a number spoofing their name? Even when it's legit, the order details sit in a chat thread nobody syncs to a system. By Friday there are forty threads and no record of what was actually ordered.

n8n WhatsApp order intake closes both holes at once. Every inbound message hits a webhook, the sender's number is checked against a registry, and authenticated orders get logged to a sheet with a reference ID and an instant reply. The unknown numbers get rejected and recorded. No manual inbox watching, no orders trapped in chat.

The content ranking for this is almost all outbound. The Twilio + WhatsApp Business Cloud integration page is a landing page with no intake workflow. The Groove WhatsApp integration guide covers sending messages and mentions webhooks in one line, but ships no sender authentication, no structured logging, and no parsing logic. Inbound, authenticated intake is the unwritten half.

What WhatsApp order intake can automate

The job isn't sending a message. It's turning a chat into a trustworthy record:

• Receive every inbound WhatsApp message through a Twilio webhook.
• Extract the sender phone and message body from the Twilio payload.
• Match the sender against a registry of approved vendors or customers.
• Log authenticated orders to Google Sheets with a unique reference ID.
• Reject and record unregistered senders automatically.
• Reply in real time, confirmed or rejected, within seconds.
• Keep configurable message templates in one Config node, no code edits.

That's intake with a gate, not a chatbot.

Why sender authentication is the part everyone skips

Here's the opinionated take: an order-intake flow without sender verification isn't intake, it's an open door. WhatsApp shows a display name anyone can set. Operations teams report the same problem over and over: a number messages claiming to be a known vendor, the info goes into a thread, and nobody can say for sure it was real until something goes wrong.

The fix is a registry check, and it's cheap. You keep a Vendors sheet with approved phone numbers. The inbound number either matches a row or it doesn't. Matched senders are trusted and logged; unmatched senders are rejected and also logged, because the rejection record is its own audit signal. A spike of rejected attempts from one number is worth knowing about.

This is the difference between a workflow that automates a task and one that automates a control. The control is what makes the automation safe to run unattended.

The WhatsApp intake pipeline

Inbound WhatsApp message (Twilio webhook POST)
        │
   Extract sender phone + message body
        │
   Fetch vendor registry from Google Sheets
        │
   IF sender in registry? ── no ──► log rejected + send "not registered" reply
        │ yes
   Log submission to Sheets (with reference ID)
        │
   Send WhatsApp confirmation reply via Twilio

Every path ends in a logged row and a reply. Nothing falls into a thread.

Step-by-step breakdown

1. Catch the inbound message

Twilio forwards every WhatsApp message your number receives to a n8n-nodes-base.webhook node via POST. This is the piece the outbound tutorials never show. You register the webhook URL as the messaging callback in your Twilio WhatsApp sender config, and from then on n8n sees every inbound message.

2. Parse the Twilio payload

A n8n-nodes-base.code v2 node pulls the two fields that matter out of Twilio's form-encoded body: the sender at From (formatted whatsapp:+1...) and the text at Body. Normalize the phone to a bare number so it'll match the registry format. Twilio's payload carries more fields, but those two drive the whole flow.

3. Authenticate against the registry

A n8n-nodes-base.googleSheets v4.5 read pulls the Vendors sheet, and a n8n-nodes-base.if v2 node checks whether the sender's number appears. Use the v2 IF schema with a string-equals condition; the legacy v1 boolean format won't validate on a current node. Matched is the trusted path, unmatched is the rejection path.

4. Log the order with a reference ID

Authenticated submissions append to a Submissions sheet. Generate a short reference ID in the Code node (a timestamp plus a random suffix works) so each order has a handle the sender can quote and you can search. The order is now out of WhatsApp and inside a system you query, which was the whole point.

5. Reply in real time

A Twilio send through n8n-nodes-base.httpRequest v4.2 (POST to the Twilio Messages endpoint) confirms the order and quotes the reference ID. Unregistered senders get a polite not-registered reply on the rejection branch. Keep both message bodies in a Config Set node so non-developers can edit the wording without opening the workflow.

Implementation patterns

Pattern 1 — Registry-as-gate. Treat the Google Sheets registry as an allowlist. The IF node is the only thing standing between an unknown number and your records, so the match logic earns scrutiny.

Sheets read (Vendors) → IF (phone in registry?) → trusted | rejected

Pattern 2 — Configurable replies. Hold every outbound message template in one n8n-nodes-base.set v3.4 Config node and reference it with ={{ $('Config').first().json.confirmTemplate }}. Operations edits the copy; the graph never changes.

Pattern 3 — Log both outcomes. Append rejected attempts to their own tab, not just successes. The rejection log is the early-warning signal for someone probing your line.

n8n nodes you'll use most

Getting started

1. Register a Twilio WhatsApp sender and grab the account SID and auth token.
2. Build a Vendors sheet in Google Sheets with one approved phone per row.
3. Add the Webhook node and set its URL as the Twilio messaging callback.
4. Write the Code node that parses From and Body and generates a reference ID.
5. Wire the Sheets read, the IF registry gate, and the two logging branches.
6. Add the Twilio reply on both paths, with copy held in a Config node.
7. Or import a tested flow and skip the wiring entirely.

Where this fits

Authenticated WhatsApp intake is one entry point into a larger operations stack. The same registry-gate idea shows up wherever an untrusted channel feeds your systems, including WhatsApp support automation, where verifying who's messaging matters as much for support tickets as for orders. Teams that route many channels into Sheets usually build it as a data pipeline so intake, validation, and logging share one shape.

A line that authenticates every sender and logs every order stops losing business in chat threads. For the wider context, see how intake feeds data validation workflows downstream, and if your orders also flow through a store, pair this with the Data Entry Hub template to route validated records into a CRM.