Qubit API v1

Getting started

From a key to your first message in five minutes.

The public API lets your own systems - a POS, an ERP, a booking engine, a website - send and read messages on the channels your business has connected, work with contacts and leads, and start automations. You never talk to WhatsApp, Meta, Telegram or an email provider yourself: the platform normalises every channel behind one contract, and your integration does not change when the business adds a channel.

What you need

  1. An application in the developer portal (Settings → Developer → Applications). An administrator of the workspace creates it, chooses its scopes and the channels it may send through, and hands you a credential.
  2. A credential. An API key (omni_live_…) for a single server, or an OAuth2 client id and secret if your system already manages tokens. Either is shown once; store it in a secret manager, not in code.
  3. A channel. At least one connected channel - WhatsApp, Telegram, email or web chat - that the administrator has allow-listed for the application. You never configure a channel yourself: you send by its name ("channel": "whatsapp") and the platform picks the allow-listed connection.

Five-minute quickstart

Every request goes to the same base URL, carries Authorization: Bearer <credential> and Accept: application/json, and answers with one envelope: { "data": … } on success, { "error": { "code", "message", "details", "request_id" } } on failure. Pick your language in the sidebar; it sticks across every page.

1. Send your first message

A free-form text can only be sent inside the customer's 24-hour service window (they wrote to you in the last day). For anything else send an approved template - see Sending messages. The Idempotency-Key header is required on every write: a retry with the same key returns the original answer instead of sending twice.

Request
Try it - send it and see the response

This is a real request. A test key still acts on its workspace: a send goes out on the connection named in the body. Point it at your own number.

Response 202
{
    "data": {
        "message_id": "01997f2a-4d7e-7d2f-8c5b-3a1d0e9f8b22",
        "conversation_id": "01997f2a-3c6d-7c1e-9b4a-2f0c9d8e7a11",
        "request_id": "2c0d8f0e-…",
        "external_reference": "ORDER-10025",
        "status": "queued"
    }
}

The 202 means accepted and queued, not delivered. Delivery happens on a worker, and the customer's device confirms it seconds later.

2. Follow the delivery

Either poll the message…

Request
Try it - send it and see the response

Sends this request from your browser and shows what the API answered. Nothing is stored here.

…or, better, register a webhook and be told. message.sent, message.delivered, message.read and message.failed arrive at your endpoint with the external_reference you sent, so you can reconcile against your own order or invoice id without storing our ids at all. See Webhooks.

Conventions worth knowing

Test and live

An application is created in a test or live environment. Test credentials (omni_test_…) work against the same API, are limited to the test channels the business connected, and are the right place to build. Swap the key and nothing else changes.

Base URL https://communication-api.artofluminaire.com Every response carries X-Request-ID; quote it when you write to support.