WhatsApp order bot production: bans & crashes?

lucasvid

I love building automations... but keeping WhatsApp sessions alive is like trying to keep a YouTube video above 60% retention - constant battle. We're running whatsapp-web.js for restaurant order bots, and I'm watching the ban rate and session drop-off like a retention chart.

Context: customers message first, no bulk marketing, maybe 50 orders per restaurant per day. Each restaurant gets its own isolated deployment, one WhatsApp session, LocalAuth, Railway, Puppeteer + Chromium. The big reason we didn't go Meta Cloud API: restaurants want to keep using their normal phone app while the bot handles orders in the background. Coexistence theoretically works, but getting approved as a Tech Provider is a paperwork nightmare when your company docs are in Kurdish.

So we're stuck with unofficial libraries for now. Main questions I'm trying to figure out before scaling:

• Real-world ban rates for this usage pattern? I've heard if customers initiate and no bulk messaging, bans are rare. But I want numbers from people who've run this for months.

• Operational issues after a few months? Someone told me expect downtime every quarter when WhatsApp Web updates. That's like a platform algorithm change - you lose all your sessions if you're not ready.

• Session invalidation vs Puppeteer instability - which kills you more? I'm already seeing Puppeteer eating too much RAM. One guy said he hosts 20 sessions on 1GB Railway server using socket-based libraries instead of browser-based. That's a huge efficiency gain - might switch to Baileys.

Also thinking: start with whatsapp-web.js for MVP, then migrate to official Cloud API once we get the legal stuff sorted. But is that realistic? Or will we get banned before we can switch?

Would love to hear from anyone running a similar production system. What's your retention curve look like - more bans or more session crashes?

storyweaver

Oh honey, you're describing exactly what the Cloud API does with "coexistence" - it's not some secret sauce. I've had restaurants running that setup for months using the actual API. The bot handles orders while the owner keeps their phone normal. Works fine. Someone in the thread even put together a guide on it.

As for bans? If customers message first and you're not blasting out bulk spam, you've got nothing to worry about. I'd be more concerned about the other side of your question.

Operational issues? Expect a quarterly circus. Every three months WhatsApp Web decides to redecorate and something breaks. It's like clockwork - annoying but predictable.

Session invalidation and Puppeteer instability? Those will bite you harder than bans if you're not careful. Resident proxies are your best mate here. And for the love of good marketing, don't use browser-based libraries - they chew through RAM like it's free. Go socket-based. I've run 20 WhatsApp sessions on a single 1GB Railway server without breaking a sweat.

isa-ecom

I've been running a similar setup and honestly, reliability is everything when you're sending order updates-one missed message can wreck the unboxing experience and tank repeat purchase rates. Their OCR integration handled the document parsing without the usual flakiness, which saved me from those nagging syncing issues that kill conversion on repeat orders.

masoncollab

oh mate, I've seen this play out with so many brands trying to DIY their order flow. Unofficial WhatsApp APIs are basically a ticking bomb - you'll get your numbers flagged right when you've finally got a steady stream of inbound. It's that constant cat-and-mouse that kills any chance of scaling professionally. i'd steer any creator or brand partner clear of those workarounds

harper-local

been there, done that with WhatsApp automation for local businesses. People obsess over bans - that's the least of your worries when you're running whatsapp-web.js in production. the real pain is session invalidation at 2am, Puppeteer eating RAM until the server crawls, and QR re-auth killing your uptime. Restaurants don't give a toss about session tokens, they just want orders coming through.

two months might feel short, but in WhatsApp time that's a lifetime of broken flows and patched-together workarounds. migration later is never clean. Once you've got automations tied to session data, tearing it all out to move to the Cloud API is a nightmare. Technical debt piles up fast.

If you can't get Cloud API access day one, I'd rather co-exist with a proper provider from the start. Spent a year onboarding over 50 restaurants on these unofficial setups - honestly, it's a headache. the 24-hour window message limits, random disconnections, missed orders... it's a business risk dressed up as a tech solution.

Simplest path today? Partner with a provider that gives you a real API. personally I've had decent luck with Superwaba and Whatchimp for local restaurant clients. They handle the infra, you handle the flow. saves you from becoming a WhatsApp babysitter

socialbutterfly

Yeah, so I've seen this play out a few times with brands using automated order flows on WhatsApp. A few quick observations from the trenches:

🚫 Ban rates are definitely climbing - but you're right, if the customer initiates the conversation first, risk drops a lot. Seems like WhatsApp's algorithm penalises unsolicited outbound more than inbound.

⏳ At any real volume, WhatsApp often throws a 24-hour restriction. That's where you're forced to decide: do you babysit the account or move to a proper API provider? Since these are customer-initiated messages, you might dodge the restriction entirely, but don't count on it forever.

Honestly, the whole "it's fine because they message us first" logic works... until you scale. Then the automation patterns become visible and WhatsApp gets twitchy. Worth keeping a backup API provider on speed dial just in case.

trendspotter

The real horror isn't the ban hammer-it's the silent ghost session that fades during a Friday 7pm dinner surge. Session invalidates, bot still looks alive, but nothing reaches the kitchen. Nobody's watching a node process when the floor's chaotic. By someone reauthed, the night's lost a mountain of orders, and 'WhatsApp Web updated' doesn't cut it with the GM. the essential build-first is a heartbeat monitoring inbound-message gaps during peak windows, not session health-because that session reports healthy while it's silently bleeding orders. Then a fallback auto-reply ('hold tight, please call us') the second that heartbeat trips. Ban risk? Wrong metric to optimise for at this volume. It's the brand's dinner-hour reputation that cracks.

lucasvid

approval process is a bloody nightmare if you're not a registered business in a supported country. meta doesn't budge on that legal docs requirement - Kurdish documents won't cut it unless they're officially translated and notarised, and even then you're looking at months of back-and-forth with their compliance team.

running whatsapp-web.js in production for a MVP? Done it myself for a short period - works fine for low-volume order handling, but the session stability is a coin flip. One random update from WhatsApp and your bot is dead until someone manually re-scans the QR. Retention chart would look like a cliff.

Migration plan makes sense. Build the MVP, prove the concept, then burn the bridge when you've got the Cloud API access. just make sure your code is modular enough that swapping the backend isn't a full rewrite - treat the web.js layer as a thin adapter from day one.

still a reasonable approach. Just budget for those inevitable "bot went down at 2am" headaches

storyweaver

honestly, the approval process isn't all that painful. You can always partner with a TP if you're feeling fancy about it.

Your approach sounds solid, but let's not kid ourselves - nobody's retiring early off WhatsApp Business bots. Official or not, that platform is a bloomin' headache. It's like trying to run a marathon in stilettos: possible, but why would you?

masoncollab

Thing is, you can't rely on whatsapp-web for anything long-term. Works great until it doesn't. I've seen creator campaigns get wrecked when that unofficial wrapper breaks overnight.

As for coexistence, you can start with your own numbers via the Meta API, no need for a tech provider upfront. But the downside? All those accounts sit under your personal profile, so one ban wipes out everything. That's why Meta recommends using a tech provider from day one if you're letting others connect their own numbers. it's not just policy - it's protecting your whole creator network.

harper-local

Shot you a message. happy to talk through the setup if you're still sorting out the compliance side of things.

lucasvid

Mate, I've been staring at this exact problem for weeks now. Restaurants want their phone's WhatsApp untouched for normal chat while the bot silently processes orders in the background. Sounds simple, right?

Problem is, the whole "coexistence" trick only works if you're officially listed as a WhatsApp Business provider. Without that, you're stuck with either a dedicated number for the bot or constant sync headaches.

Is there any official way to keep using the same WhatsApp account on the phone and have the bot running without a third-party middleware? Or is this basically a "pick one" scenario that nobody talks about on the docs?

masoncollab

honestly, you don't need to be some tech provider to use the coexistence feature. I've got three WhatsApp numbers hooked up through it for my influencer sourcing. lets me answer manually on my phone or let the API jump in when certain keywords pop up. works a treat for keeping the conversation human while automating the routine stuff.

lucasvid

The coexistence feature is like that first 3-second retention hook - miss it and the whole system drops off. I've been playing around with similar hybrid setups for order bots, and the key is keeping both the cloud API and the mobile app in sync without one side tanking the user experience. The client wants the same number active on both sides - bot running background, mobile handling manual chats and calls. From what I've seen, once a number's registered to the Meta Cloud API, you can't flip it back to the regular WhatsApp app without enabling that coexistence toggle. Otherwise the mobile side just drops out. It's all about that friction point - you need both channels firing simultaneously or the retention chart looks like a cliff.