Wevlix Docs
Developer documentation

Wevlix Messaging API

Build WhatsApp verification, notifications, and approved template messaging with project-scoped credentials, safe sandbox testing, transparent pricing, and delivery status you can operate against.

curl -X POST https://api.wevlix.com/v1/otp/send \
  -H "x-api-key: wvlx_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+12345678900"
  }'
Partners Platform Providers Embed Wevlix for managed customers with provider credentials, onboarding, templates, messaging, webhooks, and one shared wallet. Start Setup Login, retrieve a project API key, and prepare your server for messaging calls. Keys Credentials Understand dashboard tokens, production API keys, development keys, and scopes. Modes Live vs Sandbox Know exactly when Wevlix uses live WhatsApp delivery, charges balance, or simulates the send. API Template Messages Send approved authentication, utility, and marketing templates in live or sandbox mode. Core OTP Messages Use a project authentication template with a generated code or an optional code supplied by your backend. Billing Pricing Power a public calculator or calculate project-specific customer-visible quotes. Guide Statuses Read message lifecycle states and decide how your integration should react. API System Check public API availability before routing production traffic through Wevlix.

What Wevlix Provides

Wevlix is a developer-focused messaging platform built on the official WhatsApp Business Platform. Each project has isolated credentials, balance, WhatsApp configuration, templates, message history, and operational controls. Your backend calls a focused API while Wevlix handles orchestration, retries, status updates, and billing.

Verification

Send generated or provided codes and verify them through a complete server-side OTP flow.

Safe testing

Use sandbox projects and development keys to exercise the full flow without calling an upstream messaging provider or charging balance.

Template messaging

Send approved authentication, utility, and marketing templates and follow every message through its lifecycle.

Quickstart

Start in sandbox mode to exercise validation, persistence, queues, status reads, and OTP verification without contacting the live messaging network or charging the project balance.

  1. Create a project in the Wevlix dashboard.
  2. Login and retrieve the project API key from the setup endpoints, or copy it from the dashboard.
  3. Use sandbox mode while building. Sandbox sends do not call Meta and do not charge balance.
  4. Call POST /v1/otp/send from your backend.
  5. Poll GET /v1/otp/status/{messageId} or store the returned message id.
  6. Call POST /v1/otp/verify when the user submits the code.
Never call Wevlix from browser code with an API key. Keep project API keys on your server and expose your own application endpoint to clients.

Authenticate For Setup

Most teams copy a project API key from the Wevlix dashboard. Trusted first-party tooling may instead log in and retrieve it through the API. The short-lived dashboard token is only for setup operations; the project key authorizes messaging and project-scoped public APIs.

  1. Call POST /v1/auth/login with the Wevlix account email and password.
  2. Use the returned accessToken as Authorization: Bearer ....
  3. Call GET /v1/projects/{projectId}/api-keys.
  4. Choose the active key by id or name.
  5. Use its rawKey as x-api-key for project API calls.

1. Login

curl -X POST https://api.wevlix.com/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "password": "StrongPass123!"
  }'

2. Get a project API key

curl https://api.wevlix.com/v1/projects/{projectId}/api-keys \
  -H "Authorization: Bearer $ACCESS_TOKEN"

3. Send with the project key

curl -X POST https://api.wevlix.com/v1/otp/send \
  -H "x-api-key: $PROJECT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+{country_code}{subscriber_number}",
    "otpMode": "generated",
    "clientMessageId": "login_attempt_123456"
  }'
The setup token and project API key are different credentials. Do not send OTP requests with the dashboard access token, and do not expose either credential in browser code.

Credentials

Wevlix uses different credentials for different jobs. Keep them separate in your codebase so dashboard setup, production sends, and local testing never accidentally share the same secret.

Credential Used for Where to store it Important behavior
Dashboard access token Setup calls such as listing project API keys. Short-lived server session or trusted internal tooling. Returned by POST /v1/auth/login. Do not use it to send OTPs.
Production API key Live or sandbox public API calls for one project. Your backend secret manager or deployment environment. Uses the project runtime mode. Omitted expiration means the key does not expire until revoked.
Development key Safe local and staging tests with fixed development phone numbers. Local or staging backend environment only. Always simulates sends and never bills, even if the project is live.

Required headers

x-api-key: wvlx_live_or_dev_key
Content-Type: application/json
API keys are scoped. OTP integrations need otp:send, otp:status, and otp:verify. Template messaging needs messages:send and messages:read. New keys receive all currently available scopes unless you choose a narrower set.

Live And Sandbox Modes

Delivery behavior is resolved from both the project runtime mode and the key type. This keeps production keys useful in sandbox projects while making development keys safe in every environment.

Project mode Key type WhatsApp delivery Billing Best use
live Production API key Yes. Requires connected WABA and approved template. Yes, after billable delivery events. Real customer messaging and production traffic.
sandbox Production API key No. Wevlix simulates the message lifecycle. No. Backend integration tests before go-live.
live or sandbox Development key No. Development keys always simulate sends. No. Local development, staging, demos, and CI.
Live sends require a connected WhatsApp Business Account, an approved template for the requested category, supported country pricing, and enough project balance. Sandbox and development-key sends do not require WABA setup.

OTP Flow

OTP sends are a simplified, template-backed form of authentication messaging. Start with only to. Wevlix generates a six-digit code when both otpMode and code are omitted. A provided code may contain exactly four or six digits. Supplying code without otpMode is also valid and automatically selects provided mode.

POST/v1/otp/send
GET/v1/otp/status/{messageId}
POST/v1/otp/verify

1. Minimum generated-code request

{
  "to": "+12345678900"
}

2. Add your own code when your backend generates it

{
  "to": "+12345678900",
  "code": "123456"
}

Writing "otpMode": "provided" is optional when code is present. If you explicitly use "otpMode": "provided", the code is required. Do not send a code with "otpMode": "generated".

Which WhatsApp template is used?

Generated and provided codes use the same template-selection rules. In live mode, Wevlix chooses an approved, sendable AUTHENTICATION template belonging to the connected project WhatsApp account. It prefers the requested locale, then a compatible language match, then the earliest eligible authentication template.

A newly connected, Meta-verified business with no existing templates normally receives the wevlix_otp starter in English and Arabic. If the account already had templates, starter provisioning is skipped. Therefore, /v1/otp/send does not promise a fixed template name. It uses the eligible authentication template selected for that account and locale.

3. Add retry protection and locale only when needed

{
  "to": "+12345678900",
  "clientMessageId": "login_attempt_123456",
  "locale": "en"
}

Template Messaging

Use template messaging for approved authentication, utility, and marketing templates. Retrieve the Wevlix template id from the project template list, pass variable values in template placeholder order, and store the returned messageId for status reads.

GET/v1/projects/{projectId}/whatsapp-account/templates
GET/v1/templates/{templateId}/integration
POST/v1/messages/template
GET/v1/messages/{messageId}

Send an approved template

The fastest path is to request a template-specific integration example. It verifies the template against the project in your API key and returns the exact parameter order, sample JSON, and a ready-to-copy cURL command.

curl https://api.wevlix.com/v1/templates/{wevlix_template_id}/integration   -H "x-api-key: $PROJECT_API_KEY"
Do not pass a project id to this endpoint. The API key determines the project, preventing templates from another project from being exposed. The response uses variables for ordinary text and dynamic URL templates, or components when a media header requires the advanced send format.
curl -X POST https://api.wevlix.com/v1/messages/template   -H "x-api-key: $PROJECT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "to": "+{country_code}{subscriber_number}",
    "templateId": "{wevlix_template_id}",
    "variables": ["Customer"],
    "clientMessageId": "order_confirmation_12345"
  }'
The templateId is the Wevlix UUID, not Meta's template id. The number of variables must match the approved template. Wevlix maps them to the YCloud/Meta component payload. For media headers or advanced button parameters, send components in Meta's message format instead. Do not send both fields.

How variables are ordered

Wevlix orders simple values by component: text-header variables first, then body variables, then dynamic URL buttons by button position. Placeholders are scoped to their component, so body {{1}} and button {{1}} are separate values. Use the generated integration response instead of calculating this order yourself.

Creation components versus send components

Components shown in a template definition describe its approved text, examples, and buttons. They cannot be copied into a send request. Send either the generated variables array or Meta-style message components containing parameters.

Media headers

For an approved template with an image, video, or document header, use components and provide either a stable HTTPS public link or a provider media id. The media object must match the approved header type. Captions are not supported in template headers.

"components": [{
  "type": "header",
  "parameters": [{
    "type": "image",
    "image": { "link": "https://cdn.example.com/campaign.jpg" }
  }]
}]
Links must use HTTPS and must not target localhost or private network addresses. Upload-first provider media ids are supported when supplied by the configured transport; Wevlix does not expose provider credentials in customer responses.

Message Statuses

Store the returned messageId and use it to inspect delivery and verification progress. Statuses are stable string values and should be treated as an enum in your integration.

Status Meaning Recommended client behavior
accepted The request was accepted and persisted. Store the messageId. You may poll status.
queued The message is waiting for background processing or a bounded WhatsApp readiness repair. Show pending state and retry status reads with backoff.
sent Meta accepted the outbound send request. Wait for delivery, read, or failed webhook updates.
delivered WhatsApp reported delivery to the recipient device. Continue your workflow; for OTP, allow the user to enter the code.
read The recipient read the message when read receipts are available. Treat it as delivered and update any read-aware workflow.
failed Wevlix or Meta could not complete the message. Show a retry option and log the returned request id.
billing_failed The message could not be charged after a billable event. Check project balance and contact support if it repeats.

Status responses may include a recovery object while Wevlix refreshes a submitted Meta-pending template or repairs an explicitly unregistered sender or incomplete WhatsApp billing setup. Recovery uses the same message id, stops within six minutes, and does not automatically resend ambiguous transport timeouts.

Backend Code Examples

These examples are intentionally server-side. Your browser or mobile app should call your own backend, and your backend should call Wevlix.

Node.js send OTP

const response = await fetch('https://api.wevlix.com/v1/otp/send', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-api-key': process.env.WEVLIX_API_KEY,
  },
  body: JSON.stringify({
    to: '+{country_code}{subscriber_number}',
    otpMode: 'generated',
    clientMessageId: 'login_attempt_123456',
  }),
});

const result = await response.json();

Verify OTP

const response = await fetch('https://api.wevlix.com/v1/otp/verify', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-api-key': process.env.WEVLIX_API_KEY,
  },
  body: JSON.stringify({
    messageId: 'msg_123',
    code: '123456',
  }),
});

const verification = await response.json();

Pricing

Customer-facing quotes return totals only. Internal Meta fees, markup, floors, caps, and project-specific overrides stay hidden from customers.

Public landing calculator

GET/v1/public/pricing/options
GET/v1/public/pricing/countries
GET/v1/public/pricing/calculate?countryIso2=EG&category=utility&quantity=10000
GET/v1/public/pricing/telegram?quantity=100

These read-only routes require no credentials and are safe for a public website. The estimate starts at the first monthly tier and includes tier transitions across the requested quantity.

Project-specific quote

GET/v1/pricing/countries
GET/v1/projects/{projectId}/pricing/quote

Use quotes before high-volume sends or to show expected cost in your own admin tools. Actual charging happens from delivered message events.

Responses And Errors

JSON endpoints return a stable envelope with success, data or error, and request metadata. Keep the requestId when contacting support.

Success

{
  "success": true,
  "data": {},
  "meta": {
    "requestId": "f3f0d89a-...",
    "timestamp": "2026-06-16T12:00:00.000Z"
  }
}

Error

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Validation failed"
  },
  "meta": {
    "requestId": "f3f0d89a-..."
  }
          }

Common error codes

Code When it happens How to handle it
VALIDATION_ERROR The request shape, phone number, code, or required field is invalid. Fix the payload before retrying.
UNAUTHORIZED The API key or dashboard bearer token is missing or invalid. Check the credential, header name, and environment.
FORBIDDEN The credential is valid but lacks the required scope or project access. Use a key with the correct scope or adjust project permissions.
RATE_LIMITED Project, phone, or IP limits were exceeded. Back off and retry after the configured window.
INSUFFICIENT_BALANCE A live send cannot start because the project balance is too low. Top up the project balance or switch to sandbox for testing.
WHATSAPP_SENDER_NOT_READY The selected sender is not registered or ready for messaging. Sync the WhatsApp account, then retry when the sender is ready.
WHATSAPP_DESTINATION_COUNTRY_RESTRICTED Wevlix does not currently support sends to the recipient country. Do not retry to that destination; choose a supported recipient country.
WHATSAPP_SENDER_COUNTRY_RESTRICTED The selected WhatsApp sender country is not currently supported. Choose an allowed sender number or contact Wevlix support.
WHATSAPP_TEMPLATE_UNAVAILABLE The selected template is missing, paused, or not approved. Sync templates and use an approved template.
WHATSAPP_RATE_LIMITED WhatsApp temporarily limited message delivery. Use failureRetryable and retry with backoff.
WHATSAPP_MESSAGE_FAILED The message could not be delivered and no safe specific cause is available. Keep the request id and contact Wevlix support if it repeats.

Message status responses expose stable failureCode, failureReason, and failureRetryable fields. Upstream transport names and raw provider payloads are never included in customer-facing responses.

Production Checklist