How many test recipients does Meta's Cloud API test number support?

Up to five WhatsApp-enabled numbers, added and verified during API Setup. Treat that list as a strict allowlist of consenting internal numbers, never customer numbers.

Can I use the Embedded Signup sandbox to test message sends?

No. It simulates onboarding and account provisioning only. Its phone number cannot send or receive any messages, and it expires after 30 days, per Meta's own documentation.

Does WhatsApp Manager's template Preview catch formatting bugs?

No. Meta states directly that Preview does not perform a formatting check. You still need to send the actual API payload and inspect the real rendered message and webhook response.

Do I need consent to send test messages, even to my own team?

Yes. Meta's opt-in requirement applies regardless of whether the account is in a test or production state. Internal testers should know what they'll receive and be able to opt out.

Test WhatsApp Sends Without Messaging Real Customers

Testing a WhatsApp send integration on your production WhatsApp Business Account is how a bug ends up in front of an actual customer instead of a developer.

Meta gives you a genuinely free, sandboxed way to avoid that: a test phone number, a small allowlist of recipients, and a template preview flow that doesn't touch production traffic.

The catch is that this test setup is easy to half-configure. Teams frequently confuse Meta's onboarding sandbox with a message-sending sandbox, they aren't the same thing, and end up either unable to test at all, or worse, accidentally sending a broken template to a real customer list.

Set Up Meta's Test Phone Number

Every WhatsApp Cloud API app gets a free test number the moment you open App Dashboard, WhatsApp, Quickstart/API Setup. The process, per Meta's official setup docs, looks like this:

Generate a temporary access token from the API Setup screen.
Select the Meta-provided number as the sender in From.
Add your own WhatsApp-enabled internal numbers under To. This is capped at five recipients, and Meta treats this as a hard allowlist, not a suggestion.
Send the preconfigured hello_world template to confirm the pipe works end to end.
Save the test phone-number ID and WABA ID, and point a test webhook at your own endpoint so you can watch accepted, delivered, read, and inbound events land in real time.

Sending template messages through the test number does not require a payment method.

Once an internal tester replies to that first message, a 24-hour customer-service window opens, and inside that window you can test free-form service messages, not just templates, which is the closest you'll get to simulating a real support conversation without touching production.

Test Templates in WhatsApp Manager, Then Test the Actual Payload

Template testing happens in Meta Business Suite, WhatsApp Manager, Manage message templates:

Choose the template category: marketing, utility, or authentication.
Fill in representative sample values for every variable and any media placeholder, never real customer data.
Use the built-in Preview to check the rendered layout.
Submit for review and wait for an approval decision.
Once the status is active, send it from the test number to one of your five allowlisted recipients.

The part teams skip: Preview is a rendering check, not a delivery or formatting guarantee.

You still need to fire the actual API call, language code, template name, variable order or names, media headers, buttons, all of it, and confirm the webhook reports back correctly.

That's the only way to catch a mismatched variable count or a wrong language code before it happens against a live customer number.

Don't Confuse the Onboarding Sandbox With a Messaging Sandbox

This is the mistake that costs the most time. The Embedded Signup sandbox account is an onboarding simulator, not a general test environment. Per Meta's documentation, it:

Embedded Signup sandbox	Cloud API test phone number
Simulates account provisioning and onboarding	Sends and receives real messages
Expires after 30 days	Persists as long as the app exists
Cannot create additional sandbox WABAs or numbers	Comes with the app by default
Does not appear in WhatsApp Manager	Fully visible in WhatsApp Manager
Phone number cannot send or receive messages	Up to 5 allowlisted recipients, fully functional

If your team built an onboarding flow test against the Embedded Signup sandbox and then tried to reuse that same setup for message-send testing, that's why nothing was sent. It was never meant to.

Build a Dry-Run Layer Before You Touch the API

The most reliable way to keep test traffic away from real customers is to never let a test build reach the live Messages API in the first place.

That means validating everything the send would need before the network call happens:

Check the destination number against a server-side allowlist, enforced immediately before the API call, not just as a checkbox in a UI.
Confirm the selected WABA and phone-number ID actually belong to the test environment, not production.
Validate the template's approval status, language, and every variable against the template's current schema.
Verify the request would satisfy the current conversation-window rules (inside the 24-hour window for free-form, or an approved template outside it).
Log the fully normalized payload and the validation result, but never call the Messages API in this mode.

Keep test and production on genuinely separate WABAs, numbers, tokens, webhook endpoints, and templates. Sharing any of those between test and production is how a "just testing" send lands in a live queue.

Stage Your Testing, Don't Jump Straight to Volume

Work through this order and don't skip steps just because the first one passed:

Dry run. Validate the payload, log it, and send nothing.
Mocked responses. Point your integration at recorded Graph API responses and webhook fixtures to exercise your own error handling.
One real send, one recipient. Fire the actual API call to a single allowlisted internal number.
Remaining allowlisted recipients. Confirm consistent behavior across different device types and WhatsApp clients.
Separate test WABA, full integration test. Run your real send/receive/webhook pipeline end-to-end against an isolated test infrastructure.
Production, only after the destination guard is independently verified. Have someone other than the author confirm the allowlist logic actually blocks non-test numbers.

Every internal recipient should know they're receiving test messages and be able to opt out, because Meta's opt-in requirement doesn't have a testing exception.

Applying This to an MCP-Connected WhatsApp Agent

Testing gets more important, not less, once an AI agent can trigger a WhatsApp send on its own initiative through an MCP tool call. A model deciding to call a send tool during a test conversation is exactly the scenario a dry-run layer exists to catch, because there's no human clicking "send" to catch a mistake at the last second.

A dry-run pattern like this is exactly what an MCP-connected WhatsApp integration needs: validate the payload, recipient, and template variables against the live template schema before anything reaches WhatsApp.

Check with your Wati contact on the current dry-run tooling available in the MCP server, and pair whatever's available with a properly configured test WABA, following how to set up a WhatsApp Business API account, before pointing any agent at real customer numbers.

If you haven't gone through account setup yet, discovering the WhatsApp Business API covers what you're actually provisioning.

For the template side specifically, creating a WhatsApp message template walks through the variable and category rules a dry run needs to validate against. And once you're ready to see how the whole flow, MCP tool call, dry run, real send, fits together, what a WhatsApp MCP server is is the place to start.

See the Test-Mode Tooling in Action

Ready to build a WhatsApp send flow with a real dry-run path built in? Book a Wati demo and ask to see the test-mode tooling before you connect a live number.