whatsappx.si API: introduction

What can you do with the API?

With an API key you can work with the same data your team sees in the inbox:

• Conversations and messages: list conversations, read message history, start a chat by phone number, send text replies and mark chats as read.
• Contacts: list, create and delete contacts.
• Workspace data: list members, automations, message templates and knowledge base articles.
• QR-linked sessions: check the status of a number linked by QR code and fetch its QR code. Linking and unlinking the number are done in the app.
• Incoming messages in real time: forward them to your server with outbound webhooks, or listen to the live event stream (server-sent events).

Replies sent through the API are text only today.

Which WhatsApp connections does it work with?

A workspace connects WhatsApp in one of two ways, and every conversation says which one it uses in channel_provider:

When a workspace has a Meta channel, the conversation endpoints work with its Meta conversations; otherwise they use the QR-linked number.

What is the base URL?

All endpoints live under one base URL:

https://whatsappx.si/api

Some paths start with /api/v1 (for example /api/v1/contacts) and some directly with /api (for example /api/conversations). Use each path exactly as documented. Send JSON bodies with Content-Type: application/json; unknown fields in a request body are ignored.

curl "https://whatsappx.si/api/conversations" \
  -H "Authorization: Bearer $WHATSAPPX_API_KEY"

What can an API key access?

An API key acts like an agent in its workspace, with one difference: it sees the whole inbox, not only assigned chats.

• A read key can call GET endpoints. Any other method returns 403 with API key is read-only.
• Keys can never call endpoints that administer the workspace: managing members, invites, API keys, webhooks and channel settings, linking or unlinking the QR-linked number, or creating and changing automations, templates and knowledge articles. Those return 403 with API keys cannot administer workspaces. In these docs they are marked Console only: use them from the app while signed in as an owner or admin.

How do workspaces work in requests?

Every key belongs to exactly one workspace. You may still send the workspace id in the X-Tenant-ID header or the ?tenant= query parameter; if you do, it must match the key’s workspace or the request fails with 403 and API key belongs to a different workspace.

Requests made by the web app with a session cookie must always select a workspace with X-Tenant-ID (or ?tenant=).

What do errors look like?

Errors always return a JSON object with an error message. Simple actions that succeed return {"ok": true}.

{ "error": "invalid or expired API key" }

Are there rate limits?

Today only the sign-in and email endpoints are rate limited (per IP address, with a Retry-After header on 429). Requests made with API keys are not rate limited at the moment. Build in retries with backoff anyway, so your integration keeps working if limits are added.

How are timestamps and flags formatted?

• Conversations, messages and the live event stream use RFC 3339 strings in UTC, for example 2026-10-02T14:31:07Z.
• Most resources under /api/v1 (for example contacts and webhooks) use Unix seconds for created_at.
• A few flags are returned as 0 or 1 instead of true or false (for example opted_in on contacts and enabled on automations). Each field table says which.