A verb tucked into a URL, multiple pagination tokens across each module, inconsistent key naming, etc. These gaps create friction that compounds across every integration built on top of our APIs.

Hence, introducing our new REST API documentation with v3 REST APIs, which act as a comprehensive rule-book detailing proper response structures, error codes, query conventions, URL format and HTTP semantics.

💡

 Switching API Versions

To switch between the two API versions, navigate to the top-right corner of the documentation, where you will find a dropdown menu. We currently support v2 (legacy) and v3 (latest).

Here's what we have upgraded, why it's essential, and what it means for anyone building with Cliq APIs today.

What's new in v3

Along with standardization, v3 APIs ship with a substantial set of new capabilities that address the inconsistencies left by v2.

Platform components management

• Bots, slash commands, message actions, functions, datastores (databases termed as datastores in v3), and extensions were fully configurable only through the UI, which changes entirely with v3.

• Every platform component now has full CRUD API coverage (schedulers and widgets will be launched soon). Creating deluge or webhook bots, adding a script to handlers, and all of this can be automated.
  

No more endless search exploration

In v2, "search" meant fetching paginated lists, filtering, and manually applying conditional logic, thereby burning bandwidth. v3 includes dedicated search endpoints for both messages and chats, with rich filtering parameters.

Cliq UI via API

The gap between what the UI could do and what the API could do ends with v3. Like, when a user pins a message, stars a chat, or adjusts a notification preference, your integration hits a dead end.

• With v3 APIs, the chat surface is fully programmable, including creating direct and group chats, forking conversations from any message point, sending typing indicators, bulk-updating read states, and managing chat folders and local history.

• Stars, pins, and chat folders are no longer UI-only gestures; they are proper first-class resources with full CRUD endpoints that fit naturally into the same model as everything else in v3.

• And settings finally have a single, consistent home DND preferences, mobile notifications, user preferences, and keyboard shortcuts all live under /settings with a uniform GET/PUT pattern.

New documentation template

Along with the APIs and their standardization, we have revamped the documentation theme that's as dynamic as our APIs.

AI tooling

1. Interrogate implementation questions, debug edge cases, and more by clicking the AI tools dropdown, which populates the Open in Claude, Open in ChatGPT, Copy as Markdown, and View as Markdown options available on every documentation page.
   

1. Launch a Claude or ChatGPT session with the full endpoint schema already loaded in context.

1. Feed it into OpenAPI Generator for typed client SDKs, drop it into an LLM for schema-accurate code generation, load it into SwaggerHub for an interactive explorer, or wire it into your CI pipeline for contract testing.

Updated Postman collection

1. At the top of the documentation, access the Postman collection with the correct method, URL, headers, and body for every endpoint. An OAuth folder handles the full token lifecycle and automatically generates and populates both your access and refresh tokens without any manual setup.
   

1. Multi-data center support is added into environment variables, two changes switch the entire collection across the US, EU, IN, AU, JP, and CA. Fork it, pull updates as the API evolves, and keep every customization intact.
   

Glossary as a single source of truth

All the unique 25+ identifiers (BOT_ID, CHAT_ID, CHANNEL_UNIQUE_NAME, etc.) are defined once, with retrieval guides (e.g., how to retrieve via API and UI, if possible), and they're linked from every endpoint that uses them, so there's no more cross-referencing tabs or guessing what a parameter expects.

Multiple language code examples

1. cURL, Deluge, Java, JavaScript, Node.js, and Python are available copy-ready on every endpoint. Default is cURL. Use the dropdown to switch between different code examples. Pick your language, copy, and run.
   
2. Fun-fact: We've also got you covered with bonus support for C#, C# HTTPClient, Go, and JavaScript XHR 🥳
   

Endpoint-specific errors

1. Every endpoint includes a section called "Possible Error Codes." By clicking this section, you can view error codes along with their HTTP status codes and plain-language descriptions. 
2. The codes in the table match exactly the strings the API uses. The information is presented in an expandable and collapsible format to enhance the user interface and user experience.
3. The relevant error handling can be done with your custom scripts without parsing or guessing any more
   

Multiple request body examples, per endpoint

1. Some endpoints support multiple ways to use them. For those, the documentation ships multiple request body examples, each mapped to a distinct business use case, with its own response example.
   
2. Switch between them from the dropdown, understand the intent, and take it straight into your script. No reverse-engineering the schema, no guessing what a field is actually for, every example is a real, working scenario you can adapt and use
   

Technical Upgrades

Removal of verbs in URL

1. v2 APIs used verb patterns as placeholders in endpoint URLs (e.g., /resource/create or /resource/delete), and these endpoints are spread across every module.
   
2. v3 APIs remove these verb placeholders, so every state transition that previously had a unique endpoint now uses a PUT or PATCH on the resource itself, with the new state included in the request body.
   

Unified response envelope

Type uses dot notation for sub-resources: channel. member, chat.read_status, so the resource type is unambiguous regardless of nesting depth. deleted lists IDs removed since the last sync, enabling cache-consistent incremental sync without polling. You write response-parsing logic once. It works across the entire API.

Uniform pagination

Paginating through v2 APIs was genuinely frustrating. Each module used its own token, and you had to account for every variation, and there was no single pattern you could rely on across the board.

The API surface was fragmented across six different tokens: next_token, sync_token, next_set_token, start_token, next_search_token, and page_number, which meant writing and maintaining module-specific pagination code was simply the norm.

v3 fixes this by replacing all of them with exactly two tokens, used identically across every resource:

1. next_token: A cursor for forward pagination that works the same way regardless of which resource you are querying.
   
2. sync_token: Designed for incremental sync, it returns only the records that have changed since your last request, making it significantly more efficient for keeping local state up to date.

PATCH as a First-class method

1. URL Nesting: URL nesting is only used when it adds real value. If a parent ID can be understood from the authentication token, it is removed from the URL path. This keeps the URLs clean and avoids redundancy.
   
   
2. Plural resource names: Every resource name in every URL, at every nesting level is plural. Hence predictability at URL level means tooling don't need to special case anything, one common rule is applied everywhere.
   
   
3. Hyphens for multi-word segments: All multi-word segments use hyphens not camelCase, not underscores and no concatenation.
   Example: /api/v3/chats/{CHAT_ID}/pin-messages
   
   
4. Consistent Key Formatting: All request and response keys follow a consistent snake_case format. The mix of camelCase and snake_case from v2 modules has been eliminated. This ensures that generated clients and serialization logic function correctly from the outset.
   
   
5. Field Selection and Sorting: Field selection and sorting are standardized across all list endpoints. You can limit the data returned using "?fields=id, name" and control the order with "?order_by=+created_time", maintaining the same syntax throughout.
   
   
6. Granular OAuth Scopes: OAuth scopes are now more detailed and documented for each endpoint. This allows integrations to request only the permissions they need (READ, CREATE, UPDATE, DELETE), with each endpoint clearly stating the required scope.

And that's a Wrap 🚀 !