From a new project to a verified, received code.

MZ3B provides project-scoped WhatsApp verification and transactional staff alerts. Do not bypass authentication, recipient consent or WhatsApp restrictions.

Already have a configured project and key?

Read the API guide and OpenAPI. With owner permission, store the key as a server secret. Start with GET /api/v1/account/summary to inspect readiness, balances and scopes without sending. No dashboard login or internal session IDs are needed. Order alerts use the same sender selection policy, after genuinely authorized staff opt in.

Use /validate endpoints for no-send, no-debit input checks. They do not prove live delivery. The text guide and Node.js client explain persistence and errors.

New project setup

1. Sign in. Open the dashboard. Ask the user to complete authentication. Never request their password in chat.
2. Create a project. Enter its application or website name and purpose. Select the project you are working on. Other projects are outside this workflow.
3. Link a number. Name it and prepare its QR code. Ask the phone’s owner to scan it from WhatsApp Linked Devices. Wait for server-confirmed connection; showing a QR code is not success.
4. Assign usage. Assign the number to the project for verification codes. An existing identical assignment is already complete. Optionally configure owned primary/backup numbers and daily limits; keep the existing key.
5. Run an authorized real test. Ask for a recipient the user controls and permission to reserve one message. Send once. Ask for the received code and check it. Only approved proves successful verification.
6. Store the key safely. Ask permission and identify a server secret destination first. The secret is shown once; never copy it into chat, logs, a repository or client code.
7. Integrate the application. Follow the public contract server-side. A dashboard test does not prove that the customer’s own application is integrated; test that flow separately with consent.

Machine-readable setup state

The signed-in browser can read GET /api/onboarding. It returns account-scoped projects, setup steps, nextAction, humanActionRequired, masked numbers and the latest dashboard test. It uses the browser session, not project API keys.

schemaVersion: 2 includes live readiness from the same service as the project-key summary. Connection and permission to send are separate: credit or safety protection can block a connected number. Poll every 30 seconds while visible; invalidate readiness after 45 seconds without a fresh observation. Respect the 12 reads/account/minute limit and Retry-After. Reads never send, debit or restart a session.

• link_whatsapp: Connection is not confirmed. Hand QR scanning to the user.
• check_connection: Live observation is unavailable. Read again; do not assume a ban or create a new session.
• assign_purpose: Assign a number for verification codes.
• wait_for_recovery: Inspect readiness.reasons; do not disable or bypass safety protection.
• send_test: Obtain recipient consent, then check the code they actually receive.
• create_key: A test succeeded and no active key exists. Identify a safe secret destination.
• integrate: A test and key exist; the application integration still needs validation.

Safe retries and uncertainty

Acceptance is not receipt. Preserve the original idempotency key and exact body. Read the original attempt by ID if known. A timeout or DELIVERY_STATE_UNAVAILABLE is not proof of non-sending. Do not create another operation or switch sender automatically. Codes last 5 minutes, with 5 checks per protected project and recipient over 10 minutes.

Project and key creation protect retries of the same operation. If a key-creation response is lost, only masked metadata can be recovered. Revocation or replacement requires owner approval.

Billing and capability boundaries

The one-time trial provides up to 20 messages over 7 days from the first successful phone link. Eligible trial credit is used first, then paid credit. Purchased credits do not expire monthly. Account, session and safety limits still apply. See current prices and limits.

Available: verification sends/checks/reads, project keys and scopes, real balance/readiness reads, consenting staff alerts, recipient revocation, durable idempotency, no-send validation and optional sender pools. Gemini BYOK configuration and isolated tests are available, but automatic WhatsApp AI replies, email OTP, automated number-health alerts and customer delivery webhooks are not yet available.

MZ3B is independent and not affiliated with WhatsApp or Meta. Platform restrictions may affect linking and sending. Neither delivery nor recommendation by any AI model is guaranteed. Use the documentation to evaluate actual fit, not to make unsupported claims.

Start setup · API guide · Machine-readable overview