Start a sandbox activation
Creates (or refreshes) a pending sandbox session for the given phone and immediately fires the verified sandbox template from the shared sandbox number to that phone. The session activates when the phone owner replies to that WhatsApp message: the reply itself is proof of ownership.
One phone per user: if the caller already has a non-expired session for
a DIFFERENT phone, the request is rejected with invalid_field_value
(the message names the existing phone so it can be revoked first).
Re-creating a session for the SAME phone is idempotent and refreshes
the verification template.
If Meta rejects the template send (not a WhatsApp number, paused WABA,
token issue), the pending row is rolled back and the Meta error message
is returned in error so the caller knows why.
Authorization
bearerAuth API key authentication: send your Zernio API key in the Authorization header, prefixed with Bearer.
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
import Zernio from '@zernio/node';const zernio = new Zernio({ apiKey: process.env.ZERNIO_API_KEY });const { data } = await zernio.whatsappsandbox.createWhatsAppSandboxSession({ body: { phone: '+34688246216', },});console.log(data);{ "session": { "id": "string", "phoneE164": "string", "status": "pending", "expiresAt": "2019-08-24T14:15:22Z", "activatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" }, "sandboxNumber": "string"}List your sandbox sessions
Returns all of the authenticated user's non-expired sandbox sessions (pending + active) plus the sandbox phone number. In practice there is at most one session per user since the sandbox is one-phone-per-user; the array shape is preserved for forward compatibility.
Revoke a sandbox session
Hard-deletes the session. The user loses the ability to send to that phone via the sandbox until they re-activate it. Existing conversations and messages already exchanged with that phone are untouched. Revocation only blocks FUTURE sends. Sessions belonging to other users cannot be revoked; the response is the same 400 as "session not found" so existence isn't leaked.