How to Export Your Zoho SalesIQ Data

How do you export data from Zoho SalesIQ?

To export data from Zoho SalesIQ you work through the REST API v2 conversation by conversation: list conversations, pull each one's messages, download attachments individually, then save canned responses and routing rules. There is no single "export everything" button, and Zobot conversation flows have no export path at any tier.

Every endpoint, parameter and scope below was re-checked against Zoho's published REST API v2 reference on 29 August 2026. Two details trip people up before they write a line of code, so settle them first: your API host depends on which data center holds your portal, and SalesIQ returns HTTP 200 on failures as well as successes.

Step 1: Use the server URI for your data center

SalesIQ runs six independent data centers. An OAuth token issued in one region will not authenticate against another, and the developer console is regional too — registering your client at api-console.zoho.com when your portal lives in the EU is the single most common reason a first export script returns an invalid-token error.

The other value every path needs is your screen name — the portal identifier sitting between the host and /index in your SalesIQ dashboard URL. In https://salesiq.zoho.com/zylker/index the screen name is zylker.

Step 2: List your conversations

Call GET /api/v2/{screen_name}/conversations with the SalesIQ.conversations.READ scope. This is the backbone of the export: it returns conversation metadata plus the visitor's name, email and phone, so it doubles as your contact export.

Three parameters matter more than the rest. limit defaults to 20 and caps at 99, so a portal with 8,000 chats needs at least 81 requests. from_time and to_time are epoch milliseconds, not ISO dates — passing seconds silently returns an empty set rather than an error. And you page forward until the response's more_data_available flag comes back false; there is no total-count field to size the job in advance.

The remaining filters are status (open, closed, waiting, connected, missed, end), department_id, attender_id, app_id for a specific brand, email, visitor_type (lead or contact), reference_ids, updated_from_time/updated_till_time, and sort_by (in_time, end_time or updated_time). Use fields to trim the payload to the columns you actually plan to load.

Step 3: Pull the messages for each conversation

Message bodies are not in the list response. For every conversation ID you collected, call GET /api/v2/{screen_name}/conversations/{conversation_id}/messages. Note the path segment: it is /messages, and a lot of third-party write-ups still show a /transcript path that returns a 1006 invalid-URL error.

This endpoint paginates too, and its limit also defaults to 20. Long chats therefore need several calls each, keyed off the same more_data_available flag. Each message carries sequence_id, sender, type, message, and an epoch-millisecond time. Sort on sequence_id rather than time when you reassemble threads — bot messages and operator messages written in the same millisecond are common, and timestamp sorting shuffles them.

Step 4: Download attachments one at a time

Files shared in chat are not embedded in the message payload. Fetch each one with GET /api/v2/{screen_name}/conversations/{conversation_id}/attachments/{attachment_id} using the conversations.READ scope. There is no bulk attachment endpoint and no archive download, so a portal with 2,000 shared files needs 2,000 requests. Budget for this: it is usually the longest-running part of the export, and it is the part most teams discover only after they have cancelled.

Step 5: Export single chats as PDF or JSON

For compliance archiving rather than a data load, POST /api/v2/{screen_name}/conversations/{conversation_id}/export produces a formatted file. It needs the SalesIQ.conversations.CREATE scope and a body with three keys: data set to messages, info or notes, format set to pdf or json, and password.

Two constraints shape how useful this is. The data key takes one value per call, so a conversation's messages, visitor info and notes are three separate requests. And the result is mailed to the requesting agent rather than returned in the HTTP response — you are collecting files from an inbox, not streaming them into a pipeline. If your portal has GDPR password protection switched on, the password field is mandatory and the call fails without it.

Step 6: Save canned responses and automation rules

Canned replies come out of GET /api/v2/{screen_name}/cannedresponses under the separate SalesIQ.cannedresponses.READ scope. Its limit defaults to 10 and caps at 99, with a quirk worth coding around: when more records remain, SalesIQ returns one extra item beyond your requested limit as the has-more signal. Ask for 20 and you get 21. Truncate the last row or you will duplicate it on the next page.

More of your configuration is retrievable than most migration checklists assume. Lead scoring rules, visitor routing rules, chat routing rules and intelligent triggers all have list endpoints, so you can archive them as JSON instead of screenshotting them. Departments, operators, brands, tags, articles and webhook definitions do too.

What does the Zoho SalesIQ export leave behind?

The Zoho SalesIQ export cannot retrieve Zobot conversation flows. The Zobot API exposes a bot list endpoint only — no endpoint returns a bot's decision tree, trigger conditions or response text.

Rebuild those by hand from the builder screen before your portal closes, capturing each node's conditions and copy. Dashboard analytics are the other gap: SalesIQ reports are rendered in the UI, and the API returns the underlying conversation records rather than the aggregated report, so historical response-time and operator-performance charts have to be recomputed from the raw export. Anything that exists purely as a chat-window appearance setting — colour, position, greeting configuration per brand — is faster to re-enter than to reconstruct.

Where does a Zoho SalesIQ export usually break?

The failure that costs teams the most is silent: SalesIQ returns HTTP 200 on errors as well as on successes, so an export script that only checks status codes records thousands of empty conversations as a completed run.

Branch on the response body instead. A successful call carries a data key; a failed one carries an error object with a numeric code. Three codes matter during a bulk pull. 1017 ("Resource limit reached for current plan") and 1021 ("Operation is not available in the current plan") mean your tier is the blocker, not your query — worth discovering before you downgrade in your final month. 1023 is a rate-limit lockout that blocks the calling IP temporarily, which is what an unthrottled attachment loop earns.

Permissions bite too. Code 1016 fires when the operator behind the token lacks rights for the operation, and roles are scoped by department — an export run under a token belonging to a Supervisor of one department quietly returns that department's conversations only. Authenticate as an Administrator, and reconcile the count you exported against the chat totals in the Chats module before you trust the result.

What should you do before cancelling Zoho SalesIQ?

Before cancelling Zoho SalesIQ, run the full export while your subscription is still active, because plan-gated endpoints stop responding the moment you downgrade and a closed portal takes its conversation history with it.

A workable order: pull the conversation list first and store the raw JSON untouched, then messages, then attachments, then configuration. Keep the raw responses alongside whatever you load into a warehouse — re-requesting is impossible after cancellation, and reparsing a saved file costs nothing. Spot-check a handful of long conversations to confirm your pagination reassembled every message rather than the first 20.

Only then rebuild in the new platform: canned responses become quick replies, departments become teams or routing groups, and the routing rules and triggers you archived as JSON become auto-reply and assignment rules. If you are loading the archive into a database rather than another inbox, the warehouse schemas and idempotent-load SQL in our guide to exporting Intercom and HubSpot conversation data to PostgreSQL transfer directly to the SalesIQ payload shapes.