The honest tradeoff
Building it yourself gives you full control over branding, error UX, and the data model. You own the Meta App, which means you own the App Review process when permissions change, and you own the relationship with Meta as a Tech Provider.
Buying it (using Dualhook Platform, in this comparison) means accepting a few-second co-branded handoff to dualhook.com during onboarding, in exchange for offloading the Meta App, OAuth code exchange, Webhook Override subscription, sibling-WABA bookkeeping, signed lifecycle event delivery, and forward-compatibility work as Cloud API changes. End-users still see your brand throughout.
Side-by-side
Twelve areas every team owns when they implement Embedded Signup, with what each one looks like in-house vs on Dualhook Platform.
When building it yourself makes sense
- WhatsApp onboarding is your product, not a feature of your product.
- You have a full-time platform team that already maintains Meta integrations.
- Compliance or contractual reasons require you to be the Tech Provider on tenant WABAs (rare).
- You need a UI handoff that doesn't include a third-party domain even for a few seconds (rare; Embedded Signup itself still requires a Meta-whitelisted launcher).
When buying makes sense
- WhatsApp is one feature among many in your SaaS and you don't want a permanent Meta integration team.
- You want to ship the Connect WhatsApp button this quarter, not next quarter.
- You want the message-path webhooks to go Meta → your tenant directly, with no proxy or message storage on the provider side.
- You want signed lifecycle events with retry handled for you, including the ones you'd otherwise forget about (token revocation, account block, sibling-WABA conflicts).
Build vs buy: every area in detail
The twelve areas every team owns when implementing Embedded Signup, with what each one looks like in-house vs on Dualhook Platform.
| Area | Build yourself | Dualhook Platform |
|---|---|---|
| Meta App setup & permissions | You create and maintain your own Meta Business App, request whatsapp_business_management and whatsapp_business_messaging permissions, complete App Review. | Dualhook ships its own reviewed Meta App. Your tenants connect through it without you ever owning a Meta App. |
| Embedded Signup flow | You implement Meta's Embedded Signup JS SDK, handle Facebook Login state, message events from the popup, and the OAuth code callback. | One co-branded onboarding URL per tenant. Dualhook hosts the launcher page and handles the Embedded Signup popup end-to-end. |
| OAuth code exchange | You exchange the short-lived code for a permanent system user access token via Graph API and store it securely. | Dualhook exchanges and stores the encrypted token. You fetch it on demand via the audit-logged reveal endpoint. |
| Webhook Override configuration | You call POST /{wabaId}/subscribed_apps with override_callback_uri + verify_token. You debug verify-token mismatches and HTTPS handshake failures. | Dualhook configures Webhook Override for every connected WABA so message-path webhooks route Meta → your tenant's endpoint directly. |
| Multi-tenant mapping | You build your own table mapping waba_id and phone_number_id to your tenant id, plus the lookup logic for inbound webhooks. | Tenants are first-class. Pass your tenantId on session creation; every event is round-tripped with that id. |
| Sibling-WABA / shared webhook handling | Meta supports both WABA-level and phone-number-level Webhook Override. Whichever you choose, you handle conflicts when a tenant connects a second number under an already-connected WABA. | Dualhook Platform v1 uses WABA-level Webhook Override; sibling WABAs are detected and a clear waba_webhook_conflict error returns with the existing URL on file. PATCH fans out across siblings safely. |
| Lifecycle event delivery | You build durable, retried, signed event delivery: onboarding.started/completed/failed, connection.mode_resolved, connection.disconnected, and heartbeat events. | HMAC-SHA256 signed events, including connection.mode_resolved when Meta finalizes coexistence vs Cloud API, with retry schedule 1m → 5m → 15m → 1h → 6h → 24h. |
| Coexistence support | You implement Coexistence-mode flags so existing WhatsApp Business mobile app users keep their app working alongside Cloud API. | Coexistence is supported as a first-class onboarding option, including the 13-day heartbeat reminder UX for tenants who use it. |
| Health & quality monitoring | You poll Meta's phone-number health endpoint, parse status (AVAILABLE / LIMITED / BLOCKED) and quality (GREEN / YELLOW / RED), and surface this to tenants. | Built-in /health endpoints and dashboard. Refresh on demand or read the latest snapshot. |
| Token reveal & audit | You build a secrets API, no-cache headers, per-key rate limits, and an audit trail of who fetched which token when. | POST /connections/:id/reveal-secrets with Cache-Control: no-store. Every reveal is recorded against your API key. |
| Error model & idempotency | You design typed error codes, idempotency-key handling, and rate-limit headers from scratch. | Stable error codes, optional Idempotency-Key with 1-hour replay, X-RateLimit-* headers on every authed response. |
| Ongoing Meta API drift | When Meta deprecates an endpoint, ships BSUIDs, or changes Embedded Signup, you fix it. | Dualhook tracks Meta's deprecation cycle and ships forward-compatible changes (e.g. BSUID transition). |