Live Mode vs Test Mode

The API key selects the mode

Test Mode and Live Mode use the same @yanola/whatsapp methods, REST /v1 endpoints, schemas, scopes, and error envelopes. The credential prefix selects one environment for the entire request. Test Mode validates the Yanola integration and creates synthetic logs and webhook events; it never sends a WhatsApp message or calls Meta.

import { WhatsAppClient } from "@yanola/whatsapp"

const yanola = new WhatsAppClient({
  apiKey: process.env.YANOLA_API_KEY!,
})

// yalo_test_... runs in Test Mode.
// yalo_live_... runs in Live Mode.

Simulator, Sandbox, and Live compared

Activate Yanola Sandbox

Yanola Sandbox is a real-provider Test Mode path. Accept the current disclosure, select the participant country, issue the one-time JOIN code, and have that participant send JOIN to the displayed Yanola number. The code and credentials are shown only for activation and are never placed in events or logs.

A Sandbox session can be pending, active, expired, stopped, replaced, disconnected, revoked, or provider-disabled. Use reconnect to continue the project conversation after a terminal session; Yanola does not silently reactivate an old participant.

1. Send only text, image, video, document, audio, location, or contact-card service messages while the Customer Service Window is open.
2. Do not send templates: templates are not supported in Sandbox.
3. Budget at most 100 provider attempts per quota window. Failed provider attempts still count; sandbox_quota_exhausted reports the reset time.
4. Expect normal workflow execution, including external workflow side effects. Sandbox changes delivery routing, not workflow semantics.
5. Consume Sandbox lifecycle events only from Test webhook endpoints. deliveryMode remains sandbox when a failed delivery is replayed.

What Test Mode validates

Test Mode is a production-shaped API simulator, not proof of WhatsApp delivery. It is designed to find Yanola request, authentication, logging, and webhook integration mistakes before a real send. Each Agent Project may keep one active Test key and make up to 1,000 simulated sends per 31-day quota window, with a maximum of 30 per minute per key.

1. API key validity, Agent Project scope, subscription entitlement, and required scopes.
2. Request schema, E.164 phone numbers, supported message fields, and idempotency behavior.
3. Ownership, connection state, API eligibility, and optional key restriction for the from Sender.
4. Rate limits and same-environment access for reads, events, webhooks, and logs.

What Test Mode skips

1. Provider token access and provider API calls.
2. Yanola Balance reservation, deduction, and provider pricing reconciliation.
3. Provider-linked WhatsApp message persistence and real recipient delivery.
4. The live Customer Service Window requirement for non-template sends.

Environment-isolated resources

Keys, messages, events, webhook endpoints, deliveries, idempotency records, rate-limit buckets, logs, and usage records are isolated by environment.

A Test Mode key cannot retrieve a live msg_ identifier, deliver to a live webhook endpoint, or replay an event into Live Mode. The same restrictions apply in reverse.

Move from Test Mode to Live Mode

The client methods and REST paths stay the same. Production readiness is a credential and operational change, not an SDK rewrite.

1. Confirm the account subscription permits Live Mode and that Yanola Balance is available.
2. Verify the production Sender is connected and API-eligible.
3. Create a least-privilege Live Mode key and store it as YANOLA_API_KEY in the production secret manager.
4. Create separate Live Mode webhook endpoints; test endpoints never receive live events.
5. Use approved templates outside the 24-hour Customer Service Window.
6. Run a controlled live send and monitor its message, event, webhook, and usage records.

Recommended environment mapping