Building an n8n WhatsApp lead-response workflow: architecture and mistakes

Travel agencies get enquiries on WhatsApp at all hours, and most of them start the same way: "Hi, how much for Dubai in June for four people?" To answer, a consultant needs the destination, the dates, how many are travelling and a rough budget. So someone types the same questions back, over and over.

I built an n8n workflow to do that first round of questions. It's open source at github.com/codicsystems/travel-whatsapp-booking-bot. Here's how it works and where it falls short.

The shape of it

It is a single n8n pipeline, started by a webhook from Meta's WhatsApp Business Platform.

1. Check the signature. The first node recomputes the signature Meta sends with each request, using the app secret, and compares it. If it doesn't match, the request is rejected. Meta's documentation says validation is optional but recommended. I treat it as required, because the webhook URL is public and anyone can send it anything.
2. Drop the noise. Delivery and read receipts arrive at the same endpoint as messages. The workflow filters them out.
3. Route non-text. Images, voice notes, locations and documents go straight to a person. The workflow can't read them reliably, and pretending otherwise isn't helpful.
4. Extract. A language model reads the text and returns a JSON object: destination, dates as written, number and type of travellers, budget, trip type and notes.
5. Validate. The workflow checks the JSON against a list of required fields. If the output doesn't parse, nothing is guessed and the case goes to a person.
6. Reply and log. If everything is there, the customer gets a confirmation with a reference and the enquiry is logged to a sheet. If something is missing, the customer is asked only for that. If the enquiry is complex, the customer is told a person will follow up and the team is alerted by email.

The decision I'd defend

The model extracts. It never writes the reply.

Replies are templates. That means the workflow cannot quote a price, promise availability or state a refund policy, because it has no way to say those things. A travel business lives on trust and on prices that are true on the day. A model improvising in that conversation is a risk with no upside.

The same thinking sits behind the escalation rules. Groups above a set size, multi-city trips, visa questions, changes to existing bookings, medical or accessibility needs and complaints all go to a person. Anything the workflow is unsure about also goes to a person. When it fails, it should fail toward a human.

What the public URL taught me

A webhook is a door. The n8n Webhook node supports basic, header and JWT authentication, an IP allowlist and filtering expressions, and you should look at them all. For WhatsApp, the signature check is the main defence, because Meta signs each payload with your app secret.

Meta also suggests mutual TLS as an additional option and discourages IP allowlisting, because Meta changes its addresses from time to time. I'd read that section of their documentation before putting this live.

The test URL and the production URL in n8n are different. The test URL only works while you're listening in the editor, and the production URL only works once the workflow is published. I mention it because it's an easy way to lose an hour wondering why Meta's verification fails.

The mistakes and gaps

The README lists these plainly, and so should I.

No deduplication. Meta retries delivery when your endpoint doesn't return a 200, and its documentation says retries continue until one succeeds, for up to seven days. So you can get the same message more than once, and the workflow will log it twice. This is the first thing I would fix. A message ID check against the sheet would do it.

Dates are stored as written. "Early June" and "next Eid" stay as text. I chose that because turning them into exact dates is a guess, and a wrong guess looks worse than a vague one. A consultant reads the text and interprets it. A better version would hold both: the original words and a parsed range with a confidence flag.

It's not a conversation. It asks one round of questions and then hands over. If a customer replies with a half answer, a person picks it up. That is deliberate, because holding conversation state is a bigger job, but it limits what the workflow can do.

No template messages. WhatsApp restricts free-form replies outside a 24-hour window, and the workflow doesn't handle the approved-template route. Late replies are outside its scope.

Languages are untested. Arabic and Urdu extraction haven't been properly tested. Many travel enquiries arrive in those languages, so this matters more than most of the other gaps.

Data protection is yours. The workflow doesn't decide where it's hosted, how long execution data is kept or what your privacy notice says. The setup guide points at those questions, and the operator has to answer them.

Why this shape

I could have built something more impressive: a chatbot that holds a conversation, checks availability and takes a deposit. It would also be more dangerous and harder to maintain.

A small workflow that does one job, says what it won't do and hands off cleanly is easier to trust. For most agencies, the useful thing is not a robot that sells. It is a consultant who opens the sheet in the morning and sees every overnight enquiry already sorted and complete.

Running costs

Meta's pricing for conversations varies by country and category. The model call per enquiry is small next to that. I'd check Meta's current pricing for your market before you promise a client a monthly figure.

If you want to use it

Clone the repo, import workflow.json into n8n, set the environment variables, add the header row to your sheet and point Meta's webhook at the production URL. There are sample payloads for testing without Meta.

And if you improve it, send a pull request. The deduplication fix would be a good first one.