Quick start
Integrate Tabi from your backend with a workspace or channel API key (create one in the dashboard after you sign in: Developer → API keys, or from a channel's settings). All JSON APIs live under /api/v1.
Replace https://api.c36.online in the examples below with your real API host (for local Docker that is often http://localhost:3000).
Authentication
Server-to-server calls use an API key. Send it as a Bearer token (recommended) or as the X-API-Key header.
Browser / mobile apps that talk to your own backend should not embed API keys; use your backend as a proxy, or use the normal user JWT flows from POST /api/v1/auth/login when you control the client (dashboard and first-party apps).
GET https://api.c36.online/api/v1/channels HTTP/1.1
Host: api.c36.online
Authorization: Bearer YOUR_WORKSPACE_OR_CHANNEL_API_KEY
Accept: application/jsoncurl -sS "https://api.c36.online/api/v1/channels" \
-H "Authorization: Bearer YOUR_WORKSPACE_OR_CHANNEL_API_KEY" \
-H "Accept: application/json"First request
List WhatsApp (and other) channels for the workspace that owns the key. Adjust filters using the query parameters documented in the reference below.
curl -sS "https://api.c36.online/api/v1/channels" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Accept: application/json" | jq .Send a message
Queue an outbound WhatsApp message on a channel by phone number. The API creates or reuses the contact and conversation, then hands off to the same dispatch pipeline as the inbox. Replace CHANNEL_UUID with a channel id from GET /channels. If your key lists scopes, include messages:send. Keys use the tk_ prefix.
curl -sS -X POST "https://api.c36.online/api/v1/channels/CHANNEL_UUID/send" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"to":"+2348012345678","content":"Hello from our backend"}' | jq .Webhooks
Subscribe to events (for example inbound messages) from the dashboard: configure an HTTPS URL, then verify deliveries using the signing secret shown in the UI. Event names and payload shapes match the schemas in the OpenAPI document below under the webhooks / inbound sections.
For message.inbound, the data object includes metadataSchemaVersion and rawEvent (currently messaging_inbound). For message.status, data includes metadataSchemaVersion, status, direction (inbound or outbound), ids, optional providerMessageId / error, and timestamp.
For quick testing without a public URL, signed-in users can use Developer → Webhook tester after logging in.
Errors & versioning
Errors return JSON with a stable message (and often a statusCode). Treat undocumented fields as optional — we may add correlation IDs and validation details without a major version bump.
The path prefix /api/v1 is the compatibility boundary. New query parameters and optional JSON fields are additive; removing or renaming fields will be announced in release notes.
OpenAPI reference
The explorer below lists every public integration route with request/response models and copy-paste snippets. It is read-only here; enable Try it out from the dashboard after sign-in.
Coming soon
We ship the integration surface first; richer product APIs are rolling out in phases. Not yet exposed as stable public HTTP APIs (or still in active development):
- Template marketplace & publishing — cross-workspace discovery and install flows beyond the catalog API (see Automations & campaigns in the reference below for current HTTP coverage).
- Visual flow builder import/export — portable automation graphs for CI and partners.
- Richer campaign analytics — reporting APIs and segmentation helpers on top of the existing campaign endpoints.
- Partner / white-label billing hooks — usage meters and reseller-facing HTTP APIs.
Need one of these for production? Get in touch via a workspace — we prioritize APIs that unblock real integrations.
Endpoint reference
Generated from the live OpenAPI document — schemas, parameters, and request snippets for every public route.