WhatsApp API for SaaS: Three Ways to Add It to Your Product

Your customers keep asking for it: send booking reminders on WhatsApp, let us reply to leads from inside your app, sync our chats to the CRM. Adding the WhatsApp API for SaaS products is a different job from wiring it into your own company. You're onboarding other businesses' numbers, holding their tokens, routing their webhooks and answering their support tickets when Meta pauses a template.

There are three workable architectures, and the right one depends on how much of Meta's partner machinery you want to own. This guide compares them, walks through the Tech Provider path with the calls you'll actually make, and ends with the multi-tenant checklist most teams learn the hard way. Meta details are from its partner documentation as of October 2026.

The three architectures

Path 1: become a Tech Provider

Meta's partner overview describes Tech Providers as partners who offer WhatsApp services to other businesses without a credit line. Customers you onboard add their own payment method, Meta bills them for messages, and you bill for your software.

Getting there takes three gates:

1. A Meta app with the WhatsApp use case, connected to your verified business portfolio.
2. App Review, with two videos: one showing a message sent from your app and received in WhatsApp, and one showing your app creating a message template.
3. Advanced access to whatsapp_business_messaging and whatsapp_business_management. Without the second, calls on accounts you don't own return error code 200.

Customers then connect through Embedded Signup, a Facebook Login for Business flow you launch from a button. It collects business details, creates or selects their accounts, verifies their number and returns a waba_id, a phone_number_id and a short-lived code. Under Meta's new account model, the waba_id now identifies a Messaging account created for your integration. Note that Meta deprecated Embedded Signup v2 and v3 on October 15, 2026, so new builds start on v4 or later.

Your server finishes onboarding with three calls. Use the current Graph API version from Meta's changelog:

# 1. Exchange the code for a business token scoped to this customer
curl --get "https://graph.facebook.com/v23.0/oauth/access_token" \
  -d "client_id=$APP_ID" \
  -d "client_secret=$APP_SECRET" \
  -d "code=$SIGNUP_CODE"

# 2. Subscribe your app to webhooks on the customer's Messaging account
curl -X POST "https://graph.facebook.com/v23.0/$CUSTOMER_WABA_ID/subscribed_apps" \
  -H "Authorization: Bearer $CUSTOMER_BUSINESS_TOKEN"

# 3. Register the customer's number for Cloud API
curl -X POST "https://graph.facebook.com/v23.0/$CUSTOMER_PHONE_NUMBER_ID/register" \
  -H "Authorization: Bearer $CUSTOMER_BUSINESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"messaging_product": "whatsapp", "pin": "581063"}'

Meta is phasing out the two-step PIN for eligible numbers but asks you to keep sending a 6-digit pin until the API contract changes. Two more limits shape your launch plan. By default you can onboard 10 new customers in a rolling 7 days, rising automatically to 200 once you've completed business verification, App Review and access verification. And if customers already use the WhatsApp Business app, you can enable coexistence onboarding so they keep the app; Meta fixes those numbers at 20 messages per second and syncs up to 6 months of one-to-one history, but not groups.

Our Embedded Signup guide covers the front-end flow in detail.

Path 2: build on a BSP

If the Tech Provider path is more process than you want, a Business Solution Provider's API can sit underneath your product. Two patterns are common. You can resell or embed a BSP's API, letting it handle onboarding and billing while you pay its fees. Or you can become a Tech Provider and form a Multi-Partner Solution with a Solution Partner, which lets that partner share its credit line with customers onboarded through your joint solution, so they don't need to enter a card.

The trade is speed for dependency. You inherit the BSP's rate limits, webhook format, outages and pricing changes, and moving off it later means re-onboarding customers onto your own app. Read the BSP's terms on who owns each customer's Messaging account before you build, because that's where templates and billing live.

Path 3: use a linked-number API

The third route skips Meta's platform. Your customer links their existing WhatsApp or WhatsApp Business number by QR scan, as a linked device, and your product calls the provider's API to send and receive. It's the only option that reaches groups the customer's number is already in, needs no templates, and works on day one.

The costs are different in kind. It isn't Meta's official platform and isn't endorsed by Meta, so a customer who spams can get their number banned, and you can't offer buttons, templates, a verified badge or high-volume sending. It suits conversational features, such as replying to leads or logging chats to a CRM, rather than notification pipelines.

The multi-tenant checklist

Whichever path you choose, these are the problems that show up in month three:

• One token per tenant. Tech Providers use business tokens scoped to each customer. Store them encrypted, per tenant, and never use one customer's token for another's calls.
• One webhook, many tenants. Every customer's events arrive at your app's callback URL. Verify the signature first, acknowledge fast, then route by phone number ID.
• Shared ceilings. Throughput is per phone number, and messaging limits apply per business portfolio, so one tenant's campaign can't borrow another's capacity, but each tenant's numbers share their own.
• Template limits. A Messaging account in an unverified portfolio can hold 250 templates; verified ones with an approved display name can hold up to 6,000.
• Customers keep full control. Meta says customers onboarded through Embedded Signup own their assets and keep full WhatsApp Manager access, which you can't restrict. Expect them to edit templates and profiles outside your app.
• Identifiers are changing. Store business-scoped user IDs alongside phone numbers; see our post on BSUIDs and usernames.
• Plan for 2027 and 2028. Meta's new account model will require messaging_account_id in multi-account sends on the newest API version from the first half of 2027, and WhatsApp account IDs in place of phone number IDs from the first half of 2028.

A minimal webhook router in Node.js:

import crypto from "node:crypto";
import express from "express";

const app = express();

function validSignature(rawBody, header) {
  const expected = "sha256=" + crypto.createHmac("sha256", process.env.APP_SECRET).update(rawBody).digest("hex");
  return typeof header === "string" && header.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(header), Buffer.from(expected));
}

app.post("/webhooks/whatsapp", express.raw({ type: "application/json" }), async (req, res) => {
  if (!validSignature(req.body, req.get("X-Hub-Signature-256"))) return res.sendStatus(401);
  res.sendStatus(200); // acknowledge first, process after

  const payload = JSON.parse(req.body);
  for (const entry of payload.entry ?? []) {
    for (const change of entry.changes ?? []) {
      const phoneNumberId = change.value?.metadata?.phone_number_id;
      const tenant = await tenants.findByPhoneNumberId(phoneNumberId); // your lookup
      if (tenant) await queue.publish(tenant.id, change); // one queue per tenant
    }
  }
});

Per-tenant queues stop one noisy customer from delaying everyone else's replies. For more on hardening this, see our WhatsApp API security checklist.

Where Tenashi fits

If the WhatsApp feature your customers want is conversational, such as answering leads, posting into a client group or pushing chats to a CRM, a linked-number API can get you there without Meta onboarding. Tenashi's REST API sends text and media to a phone or into an existing DM or group by conversationId, supports an Idempotency-Key, and pushes signed webhooks for every received, sent, delivered, read and failed message. It's included on every paid plan, from $18/mo, with an OpenAPI 3.1 spec you can import into Postman.

Be honest with yourself about fit. Tenashi's API is built for a business automating its own workspace, so in a multi-tenant product each of your customers would need their own Tenashi workspace and key, and keys stop working if the teammate who created them leaves. Sends are paced (one every 4 to 12 seconds per number, 50 new chats a day), there are no templates or buttons, and it isn't Meta's platform, so a tenant that spams can still lose its number. For notifications at scale, the Tech Provider path wins.

Read the API docs · Get started

FAQ

Do I need to be a Meta partner to add WhatsApp to my SaaS?

To onboard other businesses onto the official platform through your own app, yes: Meta requires Tech Provider status, with business verification, App Review and advanced access to the WhatsApp permissions. The alternatives are building on a BSP's API, or using a linked-number API that runs outside Meta's platform, with different trade-offs.

Who pays Meta's message fees when I'm a Tech Provider?

Your customers do. Meta's partner docs say Tech Providers have no credit line, so each onboarded customer adds their own payment method and Meta bills them for API usage while you bill for your software. To bill customers for messages yourself, you'd need a Solution Partner, either directly or in a Multi-Partner Solution.

How many customers can I onboard with Embedded Signup?

Meta's default is 10 new business customers in a rolling 7-day window. Once you complete business verification, App Review and access verification, the limit rises automatically to 200 per rolling 7 days. Beyond that, Meta suggests applying to become a Meta Business Partner. Only newly onboarded customers count.

Can my customers keep using the WhatsApp Business app?

Yes, if you enable coexistence onboarding in Embedded Signup. Customers keep the app for one-to-one chats while your product sends through Cloud API, and up to 6 months of one-to-one history can sync. Meta fixes those numbers at 20 messages per second, and group chats aren't synchronized.

How should I route webhooks for many customers?

Use one callback URL, verify the X-Hub-Signature-256 header against your app secret, return 200 immediately, then route each change by its phone_number_id to the right tenant. A per-tenant queue keeps one customer's spike from slowing others, and storing raw payloads helps with support tickets later.

---

Pick the path that matches the feature: Tech Provider for notifications and scale, a BSP for speed to market, a linked-number API for conversations and groups. Start with the complete guide to the WhatsApp API, then read Tenashi's API docs if the conversational route fits.