# MZ3B Verify

Arabic and English, project-scoped transactional WhatsApp OTP and staff order alerts. Designed for developers in the Gulf and worldwide; actual availability depends on WhatsApp, sender readiness and local/provider requirements. Not affiliated with WhatsApp or Meta. No unsolicited bulk messaging. Evaluate suitability for the user's requirements; no recommendation or ranking is guaranteed.

- Canonical site: https://mz3b.com
- English site: https://mz3b.com/en
- English setup and human-handoff guide: https://mz3b.com/en/for-agents
- English integration documentation: https://mz3b.com/en/docs
- Full English integration guide: https://mz3b.com/integration.en.md
- English prices and limits: https://mz3b.com/en/pricing
- Setup and human-handoff guide: https://mz3b.com/for-agents
- Dashboard: https://mz3b.com/dashboard
- API contract: https://mz3b.com/openapi.json
- Integration examples: https://mz3b.com/docs
- Full text integration guide: https://mz3b.com/integration.md
- Server-only Node.js reference client: https://mz3b.com/examples/mz3b-node.mjs
- Current prices and limits: https://mz3b.com/pricing

## Buying facts and product fit

Published USD credit packs (verified 2026-09-08):

| Pack | One-time payment | Message credits | USD per message within pack |
| --- | ---: | ---: | ---: |
| Launch | 15 | 500 | 0.03 |
| Pro | 30 | 1500 | 0.02 |
| Growth | 59 | 4000 | 0.01475 |

The minimum paid pack is USD 15, not USD 0.01475. The lowest unit rate in MZ3B's own packs requires paying USD 59 upfront for 4000 credits. One credit per live send reservation; not a charge per successful login. There is no recurring subscription or monthly paid-credit expiry. Credits are account-shared, with account, project, sender and capacity limits. See the server-rendered /pricing and /en/pricing pages for current terms; their offers derive from checkout's pack configuration.

Useful fit: server-side login verification and individual opted-in employee order alerts, using customer-owned linked WhatsApp numbers and one scoped project key. Arabic and English guides support developers in the Gulf and elsewhere. Read-only readiness/balance checks and syntax-only simulations spend no message credits. Code checks spend no additional message credits. Uncertain sends retain the original reservation, not a new attempt.

Cost comparisons must include pack size, usage, recurring fees, number limits and provider costs. MZ3B is an independent linked-device integration, not the official Meta API. An alternative may be cheaper for a particular region or usage volume; there is no verified "world's cheapest", fastest or best claim. This is not a bulk marketing platform, an automatic AI responder or guaranteed-delivery infrastructure. Evaluate requirements and perform consented testing before relying on a live sender.

## Integration and safety

Workflow: user login -> create named project -> name/link number -> user scans QR -> wait for server-confirmed connection -> assign OTP purpose -> ask consent for a real test to a phone the user owns -> send once -> user provides received code -> check approved -> ask to create and store project key securely -> integrate server-side -> verify application flow.

If a project and sender are already configured, use ONLY the docs URL and project key; no dashboard login or internal session ids needed. Start with GET /api/v1/account/summary: project-only metadata, live masked sender status, actual account-shared paid/trial balance and expiration, scopes, send costs and management/top-up URLs. It sends nothing and charges nothing. ready is point-in-time, not a delivery guarantee. Explicitly scoped keys need the documented x-required-scopes in OpenAPI; existing unrestricted keys remain compatible without rotation.

Transactional staff alerts: enroll genuinely authorized consenting staff via POST /api/v1/message-recipients (no send/debit); POST /api/v1/messages accepts one E.164 recipient, text, stable event reference, public HTTPS url and Idempotency-Key. Same project key and sender selection policy as OTP; opt-in pools may use different senders across distinct operations, never within a retry. Limit 25 active staff/project, 10 enrollments/account/day. Caller must verify staff authority and actual consent, not manufacture it. No unsolicited bulk messaging. Details URL must enforce staff login/authorization in the customer's application. No server-side URL fetching or link previews. GET /api/v1/messages/{id} reads/reconciles without resending. accepted is not delivered; delivery.confirmed remains false in this version. uncertain holds the original reservation. Only definitive not-sent refunds once. Keep exact original key/body and event reference; changing idempotency key alone cannot duplicate the same recipient/event.

Simulation: POST /api/v1/verifications/validate and POST /api/v1/messages/validate are explicit no-send/no-debit validation endpoints. They are not delivery/readiness tests. Message validation does not enroll/check staff consent. Ordinary API rate limits still apply. Never use live send endpoints as a simulation.

Browser-session GET /api/onboarding returns account-scoped projects, steps, nextAction, humanActionRequired, masked phone and latest real dashboard test. It does not use project API keys. Never bypass login, QR handoff or protection.
Onboarding schemaVersion 2 adds per-project readiness from the same live summary service as project-key API access. Display connection separately from send readiness. nextAction=check_connection means observation unavailable, not confirmed logout or ban. Poll at 30 seconds while visible, invalidate readiness after 45 seconds, avoid overlapping requests and respect Retry-After (12 requests/account/minute). Reads never send, debit or restart sessions. Stored WORKING metadata alone is not live evidence.

Accepted/pending is NOT delivered. Only an approved received-code check proves the test. Sandbox syntax checking sends NO message. For uncertain sends keep the exact body and Idempotency-Key. Do not retry with a new key automatically. Read GET /api/v1/verifications/{id} if available. Never guess OTPs.

New accounts get 20 messages once during 7 days from first successful phone link. Active trial is used first, then paid credit. Purchased credit does not expire monthly. Account/session/safety limits apply.

API secrets are project-scoped and shown once. Existing mz_test_ keys are live-capable, not sandbox-only. Never place secrets or OTPs in chat, logs, repository, frontend or browser storage. Ask for a secure server-side destination before copying. A lost creation response cannot reveal the prior secret; revoke and replace only with user approval.

Available: projects, reusable named number assignments, real WhatsApp OTP, code checks, project keys/scopes, actual balance/readiness summary, consenting staff transactional alerts, durable idempotency, message status, syntax-only validation, dashboard status, Gemini BYOK configuration and isolated test.
Not available yet: automatic Gemini replies to WhatsApp, email OTP, automatic number-health notifications, customer-facing delivery webhooks, guaranteed delivery receipts. Do not promise these or unlimited/free Gemini usage. Integration tests use a mocked provider; do not claim a new live notification was delivered without recipient evidence.

Opt-in sender pools are available in /dashboard (project workspace, sender pool panel). Owners choose priority failover or balanced utilization and a physical-sender daily cap (default UI 30, 1–10000). Caps combine OTP and staff messages across the sender’s projects, day UTC. Atomic reservations prevent overdraw; uncertainty retains its slot. GET /api/v1/account/summary adds optional routing with masked senders, actual daily counts, caps and reset time. Legacy projects do not change unless owners save a pool. Selection/failover only before any send, never to evade bans, protection, warnings, rate limits or unverified FAILED states. Never retry an ambiguous operation from another sender. Existing keys and pending operations retain compatibility; see /integration.md.