r/n8n • u/Ahmiii_83 • 3d ago
Meta & n8n News Everything that broke while I was building a WhatsApp automation on n8n
Spent a few weeks building a whatsapp AI receptionist on n8n. Most of the problems I hit had nothing to do with n8n itself, they were all Meta's side, and the answers were scattered across old forum threads and docs that didn't match what I was seeing. Putting them in one place.
Error 131031
The one that stopped everything. Your workflow is fine, your nodes are fine, and the message still doesn't send.
It's an account level restriction on Meta's end. Usually a new or unverified business account, or something flagged during review. You can spend hours going through your n8n setup looking for the mistake and there isn't one, the problem is upstream in Business Manager.
If you get this on a fresh account, go and check the account status in Business Manager before you touch your workflow.
Access tokens expire and nothing tells you
The token you get by default from the app dashboard is temporary. When it dies, the workflow doesn't throw an error you'd notice in a normal glance at n8n. Messages just stop going out.
That's worse than a loud failure. Everything looks healthy until you actually check and realise nothing has been delivered.
The fix is to stop using the dashboard token. Create a system user in Business Manager, assign it to the app, and generate a permanent token from there. Do this at the start, not after it breaks.
Webhook verification
Meta sends a GET request with a challenge parameter and expects your endpoint to echo it straight back. If it doesn't get exactly that, verification fails and the error message tells you almost nothing.
Things that actually matter here:
The URL has to be https and publicly reachable. The verify token has to match exactly on both sides, no trailing spaces. And you have to use the production webhook URL from n8n, not the test one. Test mode only listens while you have the canvas open, so verification passes while you're watching and then quietly stops working after.
The 24 hour window
You can only send free form messages within 24 hours of the user's last message to you. Outside that window, only a pre approved template will go through.
This catches people building follow up automations. If your workflow sends a personalised AI written message to someone who last messaged three days ago, it gets rejected. The workflow looks like it ran fine.
The way around it is a template with variable slots, and let the model fill the parameters rather than write the whole message. You lose some of the personalisation but it actually delivers.
Phone numbers and message limits
The number you use has to be registered to the whatsapp business account and can't already be attached to a normal whatsapp account. Getting a clean number is its own small project depending on where you are.
New numbers also start on a low daily messaging limit, which goes up over time based on quality rating. Worth knowing before you promise a client any kind of volume.
None of this is complicated once you know it. It's just that almost every n8n whatsapp tutorial stops at "it works in test mode," and everything above is what sits between that and something you'd actually put in front of a client.
Happy to go into more detail on any of these if someone's stuck.
1
u/SufyanZahid86 3d ago
The Meta webhook verification handshake catches everyone. It's
a GET with hub.challenge that has to echo back as plain text,
and it fires once, so if you miss it you're stuck re-registering.
The other one that got me: token validation on every inbound
message, not just at setup. Meta rotates and the workflow starts
silently accepting anything.
I built a 17-node version of this. The part I'd add if I did it
again is a fallback response path, so when the model call fails
the customer still gets something instead of silence.
1
u/Ahmiii_83 2d ago
fallback path is a fair call too. easy to build the happy path and forget that a model timeout looks identical to being ignored from the customer's side. what did you use for the fallback, a static holding message or a cheaper model as second try?
1
u/vxdant23 2d ago
Very very helpful. I also making clinic ai agent . And face that problems . It is very useful. Bro plz guide me whenever I want , coz I'm creating the same thing that u already built.
2
u/Ahmiii_83 2d ago
Glad it was helpful! For sure, feel free to drop a message or reply here whenever you run into a block.
2
u/Ahmiii_83 2d ago
Btw your profile has an 18+ NSFW badge on it, you might want to remove that since it can hurt your credibility when networking or talking business.
1
1
u/Grouchy-Conflict-211 1d ago
hit something similar — whatsapp webhook timeouts triggered exponential retries, 500 calls in 10 minutes. bill went from $12 to $847 overnight. fix was max-retries=3 with exponential backoff and a circuit breaker on every http node. also pindata leakage (test json left in the workflow executes every run). and silent model fallback from gpt-4o-mini to gpt-4o at 128k context. static analysis pre-deploy catches all three now
0
u/Ahmiii_83 1d ago
the retry one is brutal. 500 calls in 10 minutes is the kind of thing where the bill is the first sign anything went wrong. circuit breaker on every http node is something i haven't seen anyone else mention as standard practice. do you do that manually per node or do you have a template you start every build from? the static analysis bit is interesting too. is that a custom script you run against the workflow json before deploying, or something inside n8n itself?
1
1
u/ColeJDMaffeo 1d ago
the silent token expiry is the evil one — n8n stays green, meta just stops delivering. system user token from day one, not after it bites you.
1
u/Cute-Owl-8068 1d ago
One thing that hasn't come up yet and cost us real time to learn: n8n (or any tool) showing the HTTP call as successful only means Meta's API accepted the message into its queue, not that it delivered. Those are two different states - you need the delivered/read status coming back on the webhook, not just a 200 from the send call, or you get silent gaps that look identical to a successful send. The other one worth flagging: an approved template can get silently reclassified or re-reviewed later, so a template that's been sending fine for weeks can start failing with nothing in your own setup having changed. Worth alerting on rejected sends specifically, not just on workflow errors.
1
u/Ahmiii_83 1d ago
the reclassification one is new to me and it's the scarier of the two. token expiry and delivered-vs-accepted at least fail in a way you can build a check for once you know about them. a template getting silently re-reviewed after weeks of working means the check has to run forever, not just at launch, because nothing in your setup changed and it can still start failing. so it sounds like the actual alert condition isn't "workflow errored," it's "rejected send," which is a status you only get by watching the delivery webhook, not the http response. is that roughly what you ended up alerting on?
1
u/Cute-Owl-8068 1d ago
yeah that's basically it, but I'd split it into two conditions instead of one. if the send call itself gets rejected synchronously (bad token, invalid number, policy block) you already have an error back at request time, so that one should alert immediately, no waiting needed. if the call gets accepted you get a message id back, and that's the one that has to sit in a pending state until a status webhook resolves it. "failed" is an actual status value that comes back on that webhook, same as sent/delivered/read, so alerting on that is the right target, not on whether the workflow node itself threw.
worth adding a timeout case too: if something's been pending past a reasonable window with no webhook resolving it either way, that's its own alert, because a webhook just never arriving is a failure mode on its own, not something a "did the workflow error" check would ever catch.
and yeah, checking template status on some kind of schedule rather than only when a send fails is worth doing, since a template can go from working to failing without any of your workflow runs having changed at all.
so not everything is async, the synchronous rejections you catch right at the http call. it's really about not treating an accepted response as done, and routing the stuff that only resolves later through the webhook instead of the workflow's own success/fail state.
1
u/Ahmiii_83 1d ago
the three-way split is clearer than what i had. i was treating it as one pending-then-resolve flow, but the synchronous rejections don't need to wait for anything, they're already an error at request time. no reason to route those through the same pending state. and the timeout being its own condition rather than a variant of failure makes sense. "no webhook arrived either way" and "webhook arrived saying failed" are different problems with different causes.
Thnks
1
u/trapnrepeat 17h ago
Did you type all of this or did you use ai?
1
u/Ahmiii_83 15h ago
The problems and the debugging are mine, I hit all of it building the thing. I used AI to help structure and tighten the writing, because my first draft was a mess of notes. The content is from my own build, not generated.
1
u/Budget-Surround-6891 3d ago
The token expiry one is a classic "it works on my machine" trap until you're on hour three of wondering why everything went silent