Skip to main content
The Watx API is a JSON REST API for developers who want to do from their own code what the dashboard does: send a WhatsApp message, create a contact, read a conversation, launch a campaign, or receive an event when a customer replies. It is scoped to one workspace. A key created in a workspace can only ever read and write that workspace’s data.

Base URL

Every path in this reference is relative to that base, so POST /messages means POST https://api.watx.in/v1/messages.
The dashboard host proxies the same API at https://app.watx.in/api/v1/…, which is the form older integrations use and the form the dashboard’s own examples show. Both reach the same service. Use https://api.watx.in/v1 for anything new.

Send your first message

Create a key in Settings → Developer → API keys with the messages:send scope (see Authentication), then:
You pass a phone number, not an internal id. Watx finds or creates the contact and the conversation, then sends. The reply appears in the shared inbox like any other message.
A free-form message only reaches a customer inside the 24-hour messaging window. Outside it, WhatsApp accepts an approved template and nothing else — send type: "template". See The 24-hour window.

What you can do

What the API does not cover: managing templates, automations, flows, forms, deals, sales documents and AI agents are dashboard features with no public endpoints. Sending happens on WhatsApp — Instagram and website conversations can be read through the API, but not replied to.
On Channels → WhatsApp → Templates, the code button on a template’s row shows the exact POST /messages request that sends that template, with its own sample values filled in, as curl or as a JSON body.
The feature called Campaigns in the app was called Broadcasts until September 2026. The API kept the old name: the endpoints are /broadcasts and the scope is broadcasts:send.

Versioning

The version is in the path. v1 is the only version, and it is stable: the endpoints, the response envelope and the field names above are what you can build on. Changes are additive. New fields appear on existing responses and new endpoints appear under /v1 without a version bump, so parse leniently and ignore fields you do not recognise. Renamed things keep their old name working alongside the new one — message_id was added beside whatsapp_message_id, and API keys issued under the old converse360_live_ prefix still authenticate.

Next

Authentication

Create a key, pick its scopes, send the header.

Requests and responses

The envelope, error codes, pagination, rate limits.

Webhooks

Events, signatures, retries.