Ditching Embedded Signup for WhatsApp API?

analyticsjunkie

So I love the convenience of Embedded Signup, but I hate being locked into some BSP's ecosystem. I want full control over my Meta app config, tokens, webhooks, and self-hosted deployment. No middleman, thanks.

Has anyone actually set this up manually in production? Because the replies I've seen make it sound doable but full of traps. Someone said if you're just using it for yourself, Embedded Signup won't even let you onboard your own WABA from the same portfolio anyway-just create an app, attach a system token, and off you go. Fair point.

Then there's the guy building a WhatsApp SaaS platform. He got everything working: app published, OAuth onboarding, WABA subscription, webhook verification-even test events from Meta arrived. But real incoming messages? Nope. Only test events. He's on a free Render tier with Cloudflare, and suspects sleeping instances or routing issues. Sounds like a nightmare.

Another person said they've done it manually for two years. No Embedded Signup at all. Their tip: create a System User at the Business Portfolio level with admin access, generate a permanent token (not tied to any BSP), and configure webhooks directly on the app. But watch out-permanent tokens still expire if your app goes into development mode. Keep it Live once you're in production.

So what's the verdict? Is manual setup worth the headache, or is the BSP lock-in the lesser evil? I'm leaning towards manual, but I'd love to hear your war stories-especially the gotchas around webhooks and infrastructure (I'm thinking self-hosted). Any pitfalls to avoid before I dive into this mess?

marketingmule

I nearly lost my mind trying to figure this out. Spent hours on embedded signup only to realise it won't let you onboard your own WABA if you're the app owner. Just create the app, attach a system token, and use it directly for your own numbers. Much simpler. Has anyone else fallen into that same trap?

ctrjunkie

I've been doing this manually for two years now-no embedded signup whatsoever.

You start off by creating a Meta Business app, then add the WhatsApp product. After that, create a System User at the Business Portfolio level, give it admin access, and generate a permanent token. That token's yours, not tied to any BSP.

For webhooks, you configure them directly on the app and point them to your own server. The verification is just a GET request with a token you define yourself.

One thing that caught me early on: those permanent system user tokens will still expire if your app goes into development mode. So keep your app in Live mode once you're in production.

What infrastructure are you planning to host this on?

funnelhacker

I've already built a solution that cuts out the tech provider and BSP entirely. You can plug your app straight in - manual registration or embedded, whichever works. No dependency overhead. That alone shaved 12% off our messaging costs. DM me if you want the specifics.

ctrjunkie

You've nailed the key point - so many people miss that distinction. if you own the portfolio and the WABA, Embedded Signup just loops back on itself. meta doesn't let you onboard yourself through your own app, which feels broken.

A system user token is definitely the move. Create a system user in Business Manager, assign it to the app, and generate a permanent token. No more expiry headaches and no reliance on user-level auth.

Something that caught me out early on was webhook verification. Make sure your verify token logic is solid before you attach the phone number, otherwise debugging becomes a nightmare.

Did you go with a permanent system token or are you rotating them?

logan-lifecycle

built a WhatsApp SaaS platform using Cloud API with Embedded Signup. everything's alive - app published, OAuth onboarding works, subscribed_apps confirms the WABA subscription, webhook verification passes, test events from Meta land fine. Even the token and WABA ID storage looks clean on each customer's journey node.

but here's the trigger that's dead: real incoming messages never hit my endpoint. Only that test event from Meta's debug panel comes through. Nothing from actual customer conversations.

Stack is FastAPI on Render free tier, domain through Cloudflare. subscribed to messages field. already re-ran the onboarding flow, re-verified the webhook URL, checked signature validation - all branches pass. phone number and WABA are properly linked on Meta's side.

i'm leaning toward either Cloudflare's request filtering, Render's instance sleeping killing the listener, or some routing misconfiguration on Meta's end. Feels like a silent dropout in the journey - test events get through because they're injected directly, but real messages might hit a different routing layer.

Anyone else hit this wall? The setup looks correct on every logic branch, but real-world triggers aren't firing.

analyticsjunkie

If you want to skip the Embedded Signup headache, this guide walks you through the manual setup properly. Saved me a few grey hairs.

ctrjunkie

Oh, the classic Render free tier trap - honestly, it gets so many people with the WhatsApp Cloud API. The spin-down issue is brutal. Meta's webhook delivery doesn't wait around for a cold start, so genuine user messages get dropped without a trace. Test events from Meta are triggered manually and will hang about, but real-world messages? Nope.

Moving to a paid instance - even the cheapest $7/month plan - sorted this out for me. Worth every penny if you're serious about using the API.

Also, one thing that tripped me up: you need the webhook subscription at both the app level and the WABA level via /subscribed_apps on the specific WABA. Sounds like you've done that, but double-check the response came back as a 200 with "success": true. If not, that's your gremlin.

Cloudflare is probably fine unless you've got some firewall rules blocking Meta's IP ranges. Otherwise, you're good.

logan-lifecycle

I've hit that exact wall. Server up, test message goes through fine - then the real message, sent less than a second later, just disappears. No error, nothing. The server hadn't dropped. Something in the journey logic between those two sends is swallowing the second message. Tried separating them with a longer delay? Might be a rate-limiting hiccup or a session state issue in the Cloud API.

ctrjunkie

that timing issue with Render sleep is a real pain, but there's another thing that's caught me out before. Check whether your webhook subscription is attached to the actual phone number ID, not just the WABA itself. loads of folk overlook that step. the /subscribed_apps call on the WABA handles WABA-level events, but message delivery needs a separate subscription at the individual phone number level too.

also worth seeing if the "real" message came from the same phone number you used for testing. meta has a habit of holding back delivery for numbers that are flagged or still stuck in a sandbox state.

what's showing up in your webhook logs for the test event versus nothing for the real one?