Using n8n for Facebook Messenger Automation: What You'll Hit

n8n is one of the best general-purpose workflow tools available. Self-hostable, hundreds of integrations, real code nodes when you need them. If you are wiring Gmail to Sheets to Slack, it is close to ideal.

This post is not an argument against n8n. It is a list of the specific things you have to build yourself when the workflow in question is a Facebook Messenger sales conversation — because those things are not obvious until you are three weeks in.

1. Meta app review is your problem now

To read and send page messages you need a Meta app with pages_messaging approved. With a hosted platform, that review has already been passed. With n8n, it is your app, your submission, your screencast.

Expect to record a video demonstrating the exact user flow, write a plain-English use case, and wait 3–14 days. Rejections are common on the first attempt and the feedback is often terse.

2. The 24-hour messaging window is not a cron problem

Meta only lets you send standard messages within 24 hours of the customer's last message. After that, the send fails.

In n8n this means every outbound message needs a timestamp check against that customer's last inbound message, plus branching for what to do when the window has closed. That is state — per conversation — and n8n workflows are stateless by design. You end up building a conversation store in Postgres or Redis before you can send a single reliable follow-up.

The rule itself is explained here: Meta's 24-hour messaging window.

3. Page access tokens expire

Short-lived tokens last about an hour. Long-lived page tokens last around 60 days, and they can be invalidated earlier if the admin changes their password, the app permissions change, or Meta forces a re-auth.

4. There is no inbox

This is the one people underestimate. A bot cannot handle every conversation — roughly 20–30% need a human. With n8n, when the bot gives up, where does the conversation go?

You need a place where a team member can see the thread, read the history, reply as the page, and have the bot stay quiet while they do. That is a full application, not a workflow. Falling back to "we'll check Meta Business Suite" means your team is now working in two systems that do not know about each other.

5. Conversation state and context

A sales conversation is inherently stateful. The customer says "the blue one", then "2 pieces", then gives an address across three messages. Each of those arrives as a separate webhook.

In a workflow tool, each execution is independent. Holding "this customer is midway through an order, has chosen the blue variant, and we are waiting for a phone number" means designing and maintaining your own session store, with expiry and cleanup.

6. Rate limits and delivery ordering

• Meta rate-limits the Send API per page; bursts get throttled
• Messages can arrive out of order if you fire them in parallel
• Failed sends need retry with backoff, not a red node in the execution log
• Broadcasts need queueing and pacing, or the page gets flagged

Honest comparison

Read that table honestly: n8n wins the top three rows decisively. If flexibility, self-hosting and marginal cost are what you optimise for, build it in n8n and budget a few weeks for the plumbing.

The hybrid that usually makes most sense

These tools are not really competitors, and the best setups we see use both:

1. 1A Messenger platform handles the conversation — replies, state, the 24-hour window, human handover
2. 2When an order is confirmed, it fires a webhook
3. 3n8n picks that up and does what it is genuinely great at — ERP sync, courier booking, accounting, custom reporting, internal Slack alerts

You get n8n's flexibility on the operations side without reimplementing Meta's messaging semantics by hand.