Developers

Access the Cloudax Connect API to programmatically manage agents, phone numbers, campaigns, contacts, and calls, and pull call, tool, webhook, and request logs for monitoring and reconciliation. The API follows RESTful conventions and returns JSON responses for all endpoints.

Getting Started

Creating API Keys

Cloudax supports two API-key types:

• Personal keys belong to your account. They can be read-only or read-and-write, but their effective access is always intersected with your current role permissions in the target organisation. They stop working for an organisation immediately if your membership is removed, personal-key access is disabled by RBAC, API Access is unavailable, or the organisation is archived or suspended.
• Service-account keys belong to one organisation and continue working independently of an individual's membership. Organisation administrators configure their scopes, rate limit, optional expiration, and IP allowlist from the Developers page.

Both types have:

• Name: a human-readable label such as "Cursor on my laptop" or "Production integration".
• IP allowlist: optional IPv4 or IPv6 addresses and CIDR ranges. An empty allowlist permits requests from any IP.

Available Scopes

Scopes control which endpoints a service-account key can access. Personal keys do not expose individual scope selection: read-only keys request all supported read operations, while read-and-write keys request all supported operations. On every request, Cloudax reduces that requested access to the actions the user can currently perform in the target organisation. Available API scopes are grouped by resource:

Partner sub-organisations

Legacy and Current Reseller Partners can call GET /api/v1/organisations with the organisations:read scope to list their complete sub-organisation hierarchy. Each result includes its hierarchy depth and whether it is directly manageable. To run another API operation against a directly linked workspace, the key must also have organisations:manage. Keep using the reseller API key and add this header:

X-Organisation-Id: sub-organisation-id

The key's existing resource scopes still apply. For example, updating an agent in a sub-organisation requires assistants:write.

Authentication

All API requests must include a cloudax_ (or legacy cs_) API key as a Bearer token in the Authorization header:

Authorization: Bearer your-api-key

Requests without a valid token will receive an HTTP 401 Unauthorised response. Requests with a valid token but insufficient scopes will receive an HTTP 403 Forbidden response.

Available Endpoints

The following endpoints are available through the Cloudax Connect API. All endpoints are prefixed with /api/v1. For full request/response shapes, query parameters, required scopes, and response statuses, see the read-only API Endpoints tab on the Developers page. It renders the live OpenAPI schema but does not send requests or expose API-key secrets.

Agents

Calls & Call Logs

Phone Numbers

Campaigns

Tool Logs

Webhook Logs

Chats

Tools

Webhooks

Knowledge Bases & Documents

Voices

AI agents & MCP server

Cloudax Connect ships a hosted MCP (Model Context Protocol) server so clients like Cursor, Claude, ChatGPT, Microsoft Copilot Studio, VS Code and Codex can control your workspace directly, creating agents, initiating calls, managing tools and webhooks, uploading knowledge, and more. It speaks the Streamable HTTP transport and supports secure browser sign-in for interactive clients. Sign in to Cloudax, review the requested read or write access, and approve the connection.

The quickest way to connect is the Overview tab of the in-app Developers page, which has an Add to Cursor button plus URL-only setup for Cursor, Claude, Claude Code, VS Code, Codex, ChatGPT and Microsoft Copilot Studio. Your client opens Cloudax sign-in and consent in the browser. Follow the instructions for your client below:

{
  "Cloudax": {
    "url": "https://your-domain.com/api/mcp"
  }
}

claude mcp add --transport http Cloudax https://your-domain.com/api/mcp

{
  "servers": {
    "Cloudax": {
      "type": "http",
      "url": "https://your-domain.com/api/mcp"
    }
  }
}

codex mcp add Cloudax --url https://your-domain.com/api/mcp
codex mcp login Cloudax

OAuth access belongs to your user account rather than one selected organisation. The client can work only in organisations and with actions currently available to your account. You can review and revoke access under Account → Connected apps.

Connected clients label viewing actions as read-only and actions that change data as writes. Cloudax product guidance is also available as a documentation resource, with search for finding a specific guide or workflow.

Agent reads and writes include every transfer type, post-call actions, folder assignment, department routing, speech endpointing and keyterms. Version history and published voice-agent test links are available as read-only operations. MCP clients can also list, add, edit, resolve and delete agent comments when the workspace plan includes Multi-user editing and comments; normal assistant permissions and comment ownership rules continue to apply.

AI instruction files

To make any AI agent a Cloudax expert without MCP, download one of the ready-made instruction files from the Overview tab of the Developers page. They are generated from the live API spec and use only provider-neutral vocabulary (personality names, voice-model names, and language-model names shown in the agent editor):

• llms.txt / llms-full.txt: condensed and full API reference for LLMs.
• AGENTS.md: instructions for Cursor, Codex, and most agents.
• cloudax.mdc: a Cursor rule (drop into .cursor/rules/).
• CLAUDE.md: Claude project instructions.

Request Logs

The Request Logs tab on the Developers page records every single request made against your /api/v1 endpoints, successful and failed alike. Use it to debug integrations, audit usage, and quickly spot keys that are misconfigured or being abused.

What is captured

Each entry shows:

• Time: when the request was received (UTC, displayed in your local timezone).
• Method: the HTTP verb (GET, POST, PATCH, DELETE).
• Endpoint: the full path that was called, e.g. /api/v1/call-logs?limit=50.
• Status: the HTTP response code, colour-coded as success (2xx), client error (4xx), or server error (5xx).
• Duration: the time taken to handle the request, in milliseconds.
• API Key: the human-readable name of the key that made the request, plus its masked prefix (for example cloudax_****a1b2).
• IP Address: the originating IP of the caller, useful for IP-whitelisting and abuse investigation.

Click any row to open a detail panel with the full request body, response body, any error message, the user-agent, and the exact timestamp, so you can reproduce and debug the call without leaving the dashboard.

Filtering and search

The Request Logs tab supports free-text search across the endpoint, error message, IP address, and API-key name, plus structured filters for:

• Status: Success (2xx), Client error (4xx), or Server error (5xx).
• Method: restrict to a single HTTP verb.
• API Key: show only requests made by a specific key, which is ideal when isolating issues to a single integration.

The header card surfaces 30-day rolling stats: total requests, success / 4xx / 5xx counts, average duration, and your top-5 most-called endpoints, so you can eyeball traffic health at a glance.

Rate Limiting

A key may have its own requests-per-minute limit. Endpoint limits also apply: call-log lists and statistics allow 20 requests per minute, individual call logs and calls endpoints allow 30, general and assistant endpoints allow 60, and webhook-management endpoints allow 100. The effective limit is the first applicable limit reached. Exceeding a limit returns HTTP 429 Too Many Requests.

Per-key and current V1 endpoint limit responses include a Retry-After header. Implement backoff and do not assume that every legacy call-log response includes that header.

IP Whitelisting

For additional security, you can restrict API access to specific IP addresses. When IP whitelisting is enabled, only requests originating from your approved IP addresses will be accepted; all other requests will be rejected with an HTTP 403 Forbidden response, regardless of whether a valid API key is provided.

For personal keys, open Account → API keys and set the allowlist while creating the key or edit it later with the shield action. Organisation administrators configure service-account key allowlists from Developers → API Keys. Both support individual IPv4 and IPv6 addresses plus CIDR ranges. This is especially useful for production integrations whose requests originate from known networks.