Zoho Cliq REST APIs v3 - A Complete Guide to What's Changed & Why

Zoho Cliq REST APIs v3 - A Complete Guide to What's Changed & Why



APIs are not just consumed by a developer with numerous automations and a series of open browser tabs. They are parsed by LLMs, fed into agent pipelines, and auto-completed by AI coding assistants that have zero tolerance for inconsistency.

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).

Version switcher dropdown showing V2 and V3 (Latest) options in the top-right corner of Zoho Cliq API Docs

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


  • 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.

  • 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.

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.

OpenAPI Specification, per resource and as a full bundle


  1. Every module overview page ships a module-specific OAS .yml file, and the complete openapi-all.zip bundle is always one click away.
  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

v2 responses had no consistent shape: some were bare, some wrapped, some ad hoc per endpoint, and all were different. v3 uses one envelope everywhere.
  1. {  
  2.   "type": "bot",  
  3.   "data": { ... }
  4. }

  6. For list responses, the same envelope extends naturally:
  7. {  
  8.   "type": "bot",
  9.   "next_token": "NTB8MTc1Nj...",
  10.   "sync_token": "NTB8MTc3Nz...",
  11.   "deleted": ["53719000001620003"],
  12.   "data": [ ... ]
  13. }
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.
Write your pagination logic once, and it works everywhere.

PATCH as a First-class method

In the v2 API, POST and PUT methods were used for almost everything, including partial updates. However, v3 enforces a more proper usage of HTTP methods. PATCH, in particular, is now utilized correctly and consistently.

This means that when updating two fields on a bot, you no longer need to resend the entire configuration. Instead, you only send what has changed, and the rest remains untouched. 

Example:
  1. PATCH /api/v3/bots/{BOT_ID} 
  2. {  
  3.   "name": "CRM Bot",  
  4.   "scope": "organization"
  5. }

Further additions

  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 🚀 !

v3 is live, but it's not done yet. More modules, endpoints, relevant MCP tools and features are on the way, and they will all meet the same high standards you see here
Thank you for building on Cliq, for pushing us to improve, and for trusting us with your integrations.

Try it out now, and if you have any feedback, suggestions or need help integrating our APIs into your internal workflows, please reach out to support@zohocliq.com, and we'd be happy to help :)

💌 With love,
Team Zoho Cliq

    • Sticky Posts

    • Zoho Cliq REST APIs v3 : A complete guide to what's changed and why 

      APIs are not just consumed by a developer with numerous automations and a series of open browser tabs. They are parsed by LLMs, fed into agent pipelines, and auto-completed by AI coding assistants that have zero tolerance for inconsistency. A verb tucked

    • Cliq Bots - Post message to a bot using the command line!

      If you had read our post on how to post a message to a channel in a simple one-line command, then this sure is a piece of cake for you guys! For those of you, who are reading this for the first time, don't worry! Just read on. This post is all about how

    • Automating Real-Time Zoho Bookings Alerts in Zoho Cliq

      Enable your teams to respond in seconds by bridging the gap between booking confirmation and team notification. No sticky notes, no calendar nudges and no follow-up frenzies. For businesses that rely on scheduled appointments, real-time visibility is

    • Add Claude in Zoho Cliq

      Let’s add a real AI assistant powered by Claude to your workspace this week, that your team can chat with, ask questions, and act on conversations to run AI actions on. This guide walks you through exactly how to do it, step by step, with all the code

    • Automate attendance tracking with Zoho Cliq Developer Platform

      I wish remote work were permanently mandated so we could join work calls from a movie theatre or even while skydiving! But wait, it's time to wake up! The alarm has snoozed twice, and your team has already logged on for the day. Keeping tabs on attendance