How to Export Data from Zoho Desk: Methods, Limits & API Guide

What Data Can You Export from Zoho Desk?

Zoho Desk splits the export problem in two: Export for individual module CSVs and Data Backup for an account-level snapshot that includes threads, comments, time entries, and attachment links. The REST API covers everything else. (help.zoho.com)

Fully exportable in practice: tickets, contacts, accounts, agents, and most other flat standard-module records. Partially exportable: threads, comments, attachments, KB hierarchy, and custom-field schema. Hard documented gap: forum topics.

[For engineering] The native UI CSV export silently omits ticket threads, comments, and time entries. If you export a Tickets CSV, you get ticket-level metadata — subject, status, assignee, custom fields — but zero conversation history. This is the most common surprise for teams attempting a CSV-based migration. The UI export also omits internal system IDs for relational mapping. Without those IDs, you would need to fuzzy-match on email addresses or names to rebuild parent-child relationships between contacts, accounts, and tickets in a destination system.

If you're planning to move this data into another platform, the export is only step one. For migration-specific guidance, see our guides on Zoho Desk to Freshdesk migration, Zoho Desk to Intercom migration, or Zoho Desk to Zendesk migration.

Export Methods: Every Way to Get Data Out of Zoho Desk

There are five practical paths to extract data. The right choice depends less on record count than on whether you need conversation history, attachments, repeatability, or no-code execution. (help.zoho.com)

One distinction worth knowing: Skyvia supports Zoho Desk for ETL, export, replication, and sync — but Skyvia Backup does not support Zoho Desk. That matters if your project is backup-oriented rather than reporting-oriented. (docs.skyvia.com)

[For PMs] Native UI Export and Data Backup require zero engineering but are only available on Professional and Enterprise plans. Free, Express, and Standard users must use the API or third-party tools. ETL/reporting tools require some technical configuration. The REST API requires a developer experienced with OAuth 2.0. A managed service offloads the engineering entirely.

Native UI Export: Step by Step

If you only need flat records — ticket metadata, contact lists, account data — the module export UI is the fastest path. It will not give you conversation history.

1. Select a specific department from the top navigation. Export is department-specific and is not available from the "All Departments" view. For multi-department instances, you must repeat the export process for each department separately and merge the results downstream. (help.zoho.com)
2. Go to Setup → Data Administration → Export and click New Export.
3. Select the module (Tickets, Contacts, Accounts, Tasks, etc.).
4. Choose your export scope: All Records, Export Based on Views, or Export Based on Criteria.
5. Select All Fields or Specific Fields.
6. Set the time frame using Created Time, Closed Time, Modified Time, or Completed Time, with predefined or custom date ranges.
7. Optionally encrypt with a password.
8. Click Export and download the CSV from export history. The download link is valid for 7 days.

Native UI export limits:

• 50,000 records per export, one module at a time.
• All Date/Time columns export in GMT regardless of the user's timezone.
• Agent export disables views and criteria — you can only export all agents.
• Article export disables criteria-based filtering.
• Only the first five lookup fields export both the lookup ID and lookup name. Additional lookups export only the ID. (help.zoho.com)
• Native export cannot export blueprint views such as Active Blueprint Tickets.
• Department-scoped only. There is no "export all departments at once" option in the UI. For organizations with many departments, this adds significant manual overhead.

The critical gap: The CSV file contains only top-level metadata per module. It does not contain conversation threads, agent comments, time entries, or attachments. If you are migrating to a new helpdesk, a ticket CSV without conversation history is effectively useless for preserving customer context.

Data Backup: Step by Step

For broader extraction that includes threads and comments, use the Data Backup tool. This is Zoho Desk's intended path for disaster recovery, compliance snapshots, and migration staging.

1. Log in as the primary contact. Only the primary contact can create or download backups.
2. Go to Setup → Data Administration → Data Backup.
3. Choose Full Backup (all data) or Custom Backup (limited to a 31-day window).
4. Optionally encrypt with a password.
5. Click Download Now. The backup produces a ZIP file containing multiple CSV files — one per module.

Data Backup file structure: The ZIP contains a flat directory of CSV files named by module — e.g., Tickets.csv, Threads.csv, Comments.csv, Contacts.csv, Accounts.csv, Attachments.csv (metadata and download links), TimeEntry.csv, Tasks.csv, Calls.csv, Events.csv, Products.csv, Articles.csv, Agents.csv, Teams.csv, Departments.csv. Each CSV includes Zoho internal IDs that serve as foreign keys across files (e.g., ticketId in Threads.csv maps to id in Tickets.csv). These IDs are critical for reconstructing relationships.

Data Backup constraints:

• 10 million record hard limit. If your instance exceeds this, the backup will fail and you must contact Zoho support. (help.zoho.com)
• The download link expires after 7 days.
• After a full backup, you cannot initiate another for 30 days.
• Scheduled backups are available weekly, bi-weekly, monthly, or quarterly. The first scheduled run is full; later runs include only new and modified data.
• Only one scheduled backup can be created per month.
• Not department-scoped. Unlike UI Export, Data Backup covers all departments in a single operation.

The backup covers: tickets (with threads, comments, time entries, and attachment links), contacts, accounts, activities (tasks, calls, events), products, KB articles, agents, teams, and departments. Forum topics are explicitly excluded from backup.

API-Based Export: Endpoints, Pagination, and Rate Limits [For Engineering]

For full-fidelity export — every thread, comment, physical attachment, and relational link — you need the Zoho Desk REST API. The API is available on all editions, including Free, though credit allocations vary significantly (see rate limits below).

Authentication

Zoho Desk uses OAuth 2.0. Register your application at api-console.zoho.com, obtain a Client ID and Client Secret, then generate access tokens via the Authorization Code flow or the Self-Client flow for server-to-server scripts. Access tokens expire after approximately 1 hour; use refresh tokens for long-running extractions. Include both the Authorization and orgId headers in every request. Use the data-center-specific api_domain from the token response as your base URL — not a hardcoded domain. (desk.zoho.com)

Data center base URLs:

Always use the api_domain returned in your OAuth token response rather than hardcoding these values.

orgId is available in Setup → Developer Space → APIs within the Zoho Desk admin panel.

If you still have old scripts using permanent auth tokens, treat them as technical debt — Zoho has deprecated auth-token authentication in favor of OAuth. (docs.skyvia.com)

Key Endpoints for Export

Department Scoping in the API

Unlike the UI Export, the API is not inherently department-scoped for most endpoints. However, the departmentId parameter is required or recommended on many listing calls (tickets, KB articles, etc.). For multi-department instances, iterate over all departments obtained from GET /api/v1/departments and pass departmentId as a query parameter on each listing call. Some endpoints (contacts, accounts) are portal-wide and do not require department scoping.

Pagination

Zoho Desk listing APIs use offset pagination via from and limit parameters. Zoho's public documentation is internally inconsistent on the specifics: the general API introduction describes a maximum of 50 resources per request, while endpoint-specific docs for tickets show limit values up to 100. In practice, plan around 50 as the safe floor, then test 100 per request on the specific endpoint and data center you will use in production. Loop until the returned array is shorter than limit or empty. (desk.zoho.com)

Delta / Incremental Export Strategy

For recurring syncs or incremental backups, avoid re-exporting the entire dataset each time. Use the modifiedTime filter on listing endpoints to retrieve only records changed since your last export:

GET /api/v1/tickets?modifiedTimeRange=2024-01-15T00:00:00Z,2024-01-22T00:00:00Z&sortBy=modifiedTime

Store a high-water mark (the modifiedTime of the most recently modified record in your last sync) and use it as the lower bound in your next run. This approach dramatically reduces API credit consumption for ongoing syncs. Note: modifiedTime filtering is available on tickets, contacts, and accounts, but not on all sub-resources (threads, comments). For child objects, you may need to re-fetch threads/comments for any ticket whose modifiedTime exceeds your high-water mark.

API Credits and Rate Limits

Zoho Desk uses a credit-based rate limiting model, not a simple per-minute request cap. Credits are consumed per API call and vary by the record range being accessed.

Daily credits by edition (per 24-hour cycle, resets at midnight data center time):

Credit cost scales with pagination depth. Early-range listing calls (records 1–2,000) cost approximately 3 credits each. Mid-range (2,001–10,000) costs 10 credits. Deeper ranges (10,001–100,000) cost 50 credits, and very deep ranges cost 100 credits. This means naive high-offset API exports become expensive long before network throughput is the bottleneck. (desk.zoho.com)

Concurrency limits (simultaneous active API calls shared across all OAuth integrations for the portal):

When credits are exhausted or concurrency is exceeded, the API returns HTTP 429. Zoho's documentation does not clearly guarantee a Retry-After header in all 429 scenarios, so implement exponential backoff regardless. (desk.zoho.com)

Example Extraction Script

import random
import time
import requests
 
BASE = f"{api_domain}/api/v1/tickets"
HEADERS = {
    "Authorization": f"Zoho-oauthtoken {access_token}",
    "orgId": org_id,
}
 
from_idx = 1
limit = 100  # fall back to 50 if your endpoint or data center rejects 100
rows = []
 
while True:
    try:
        resp = requests.get(
            BASE,
            headers=HEADERS,
            params={"from": from_idx, "limit": limit, "sortBy": "createdTime"},
            timeout=60,
        )
    except requests.exceptions.ConnectionError:
        time.sleep(5)
        continue
    except requests.exceptions.Timeout:
        time.sleep(10)
        continue
 
    if resp.status_code == 429:
        # Zoho docs do not guarantee Retry-After in all cases
        sleep_for = int(resp.headers.get("Retry-After", 0)) or min(
            120, 2 ** (4 + random.random())
        )
        time.sleep(sleep_for)
        continue
 
    if resp.status_code == 401:
        # Access token expired mid-extraction — refresh and retry
        access_token = refresh_access_token(refresh_token, client_id, client_secret)
        HEADERS["Authorization"] = f"Zoho-oauthtoken {access_token}"
        continue
 
    if resp.status_code >= 500:
        # Zoho server error — retry with backoff
        time.sleep(30)
        continue
 
    resp.raise_for_status()
    batch = resp.json().get("data", [])
 
    if not batch:
        break
 
    rows.extend(batch)
    from_idx += len(batch)
 
    if len(batch) < limit:
        break
 
    time.sleep(0.5)  # reduce concurrency spikes

Throughput math: On an Enterprise plan with 50 users (150,000 daily credits), listing tickets at 100 per call costs ~3 credits each in the first 2,000-record range. But each ticket also requires separate calls for threads, comments, and attachments. A realistic sustained export rate for a full dataset — including child objects and retry backoff — is roughly 5,000–10,000 tickets per hour. For 100,000 tickets with full history, plan for 200,000–300,000 total API calls spread over several days of sustained extraction.

Community API for Forum Topics

Forum topics are the one data type explicitly excluded from both UI Export and Data Backup. Zoho provides a Community API for programmatic access, though it is less well-documented than the core Desk API.

Key endpoints:

These endpoints use the same OAuth 2.0 authentication and orgId header as the core API. Pagination follows the same from/limit pattern. Credit costs apply. Coverage is read-only — you can extract forum data but cannot programmatically create topics via the Desk API (community contribution endpoints are separate).

For organizations with active community forums, export forum data before deactivating your Zoho Desk account, as there is no other recovery path.

Does Zoho Desk Let You Export Attachments?

No native export path gives you physical attachment files. The UI CSV export does not include them at all. The Data Backup includes secure download links in the CSV output, but not the files themselves. To download actual binaries, you must call the API. (help.zoho.com)

A safe attachment export workflow:

1. Run Data Backup or extract ticket, thread, and comment metadata via API.
2. Collect every attachment href or secure download URL.
3. Download the binary files in a second pass using GET /api/v1/tickets/{ticketId}/attachments/{attachmentId}/content with a valid OAuth token.
4. Store a mapping table: zoho_attachment_id → source ticket/thread/comment → downloaded file path/checksum.
5. Verify file integrity by comparing the downloaded file size against the size field in the attachment metadata response.

Attachment gotchas:

• Inline images: Images pasted directly into ticket replies are often hosted on Zoho's CDN and referenced as img src URLs in the thread HTML. If your Zoho Desk account is later deactivated, every inline image breaks permanently. For migration scenarios, parse the HTML body of every thread, download all images from Zoho domains (desk.zoho.com, desk.zoho.eu, writer.zoho.com, etc.), and rewrite the URLs to point to your new hosting destination.
• File size limits: Zoho Desk allows attachments up to 20 MB per ticket (or higher on Enterprise plans). Bulk downloading terabytes of attachments will heavily consume your daily API credits.
• Thread vs. ticket attachments: Attachments can exist at three levels — ticket-level, thread-level, and comment-level. Each requires a different API endpoint to download. Ensure your extraction script covers all three.
• No documented bulk download bandwidth cap exists, but the credit system, concurrency limits, and 7-day backup download window act as effective throttles.

What Data Cannot Be Exported from Zoho Desk?

Be explicit in your planning. Some data has no native export path at all, and configuration data is a separate problem from business data.

If you care about auditability, treat configuration as a separate workstream from data. Zoho exposes some configuration surfaces via APIs (organizationFields, layouts, layoutRules, dataSharingRules, slaPolicies, blueprints, profiles, roles), but there is no single native export bundle for operating logic. The difference between "I have my records" and "I can rebuild the system" is a configuration inventory built one API call at a time. (help.zoho.com)

Zoho Desk internal IDs are portable as reference keys for mapping during migration but have no meaning in a destination platform. Maintain a permanent ID crosswalk table to preserve relationships (contact → ticket, account → contact) during any migration.

Note on Zoho Desk Sandbox: If your organization uses a Zoho Desk sandbox environment, be aware that sandbox data is separate from production. The sandbox has the same API endpoints but its own orgId. Export capabilities and limits are identical to production, but sandbox data is not included in production Data Backups.

Data Format, Encoding, and Cleanup After Export

Zoho Desk gives you CSV from native UI export, a ZIP of multiple CSV files from Data Backup, and JSON from the REST API. CSV files use UTF-8 encoding. All Date/Time columns in CSV exports are written in GMT regardless of the user's timezone. (help.zoho.com)

Common cleanup tasks after export:

• Timezone normalization: Convert GMT timestamps to your destination platform's expected format or warehouse timezone model. Always prefer API UTC timestamps over localized CSV timestamps for migrations. API JSON responses return timestamps in ISO 8601 format (e.g., 2024-01-15T14:30:00.000Z).
• HTML in text fields: Thread content and ticket descriptions export as raw HTML. Ensure your destination can render it, or write a parser to convert to Markdown or plain text. Common Zoho HTML patterns include <div> wrappers, <br> line breaks, and <span style="..."> inline formatting.
• Orphaned references: If tickets are deleted during a long-running API extraction, or if you export contacts before accounts, records may reference IDs that don't exist in your export. Check for orphaned threads referencing missing ticket_id values. Mitigate by exporting parent records (accounts) before children (contacts, tickets).
• Lookup field limits: Beyond five lookups, the CSV export includes only the lookup ID, not the display name. Enrich these by joining against module exports or API responses.
• Custom field definitions: Export field definitions separately using the organizationFields and layouts APIs so your custom fields are not just opaque cf_* columns in a CSV. (desk.zoho.com)
• Encoding: Ensure extraction scripts enforce UTF-8. Zoho Desk supports global characters, and failing to enforce UTF-8 will result in corrupted text (mojibake) in customer names and ticket bodies.
• Picklist and multi-select values: These export as plain text strings. Multi-select fields use a semicolon (;) delimiter. Validate that your destination system's import correctly splits these.

Post-export validation checklist:

1. Match record counts for each exported object against Zoho Desk UI totals or API counts.
2. Spot-check at least 10–20 tickets across different statuses, departments, date ranges, and channels for thread/comment completeness.
3. Verify all attachment download links are accessible and download a sample set — open the files.
4. Check that custom field values exported correctly, especially picklists and multi-select fields.
5. Validate date formats and timezone offsets.
6. Confirm no truncation on long-text fields (descriptions, resolutions).
7. Preserve original Zoho IDs as external IDs for migration mapping.
8. Verify thread ordering within tickets is chronologically correct (sort by createdTime).
9. Confirm that inline images in thread HTML bodies are still accessible and rendering.

Export for Migration vs. Backup vs. Compliance

These are three different jobs with different requirements.

Migration requires the most work. You need full relationship fidelity (ticket → contact → account), an ID mapping table between source and destination, thread/comment ordering preserved, and attachments physically downloaded and re-uploaded. The export format must match your destination's import requirements.

For migration, use Data Backup or the REST API — not module CSVs alone. Zoho Desk Departments typically map to Groups in destination platforms, and Threads/Comments map to Conversations or Replies. For platform-specific mapping guidance:

• Zoho Desk to Freshdesk Migration
• Zoho Desk to Zendesk Migration
• Zoho Desk to Intercom Migration

For general migration strategy, see our help desk data migration playbook.

Comparison note for Zoho CRM users: If you also use Zoho CRM, its export capabilities differ significantly. Zoho CRM supports bulk CSV export with higher native limits (up to 200,000 records via data export) and has a more mature bulk API. However, CRM does not share an export tool with Desk — you must export each product separately and map shared records (contacts, accounts) by email or Zoho ID.

Backup needs a complete, periodic snapshot. Zoho Desk's scheduled Data Backup handles this for most requirements. The first scheduled run is full; later runs include only new and modified data. The 10-million-record cap and 30-day cooldown between full backups are the main constraints. Store the ZIP in AWS S3, Google Cloud Storage, or equivalent cold storage with versioning enabled.

Compliance (GDPR / DSAR) requires the ability to export or erase a specific individual's data. Zoho Desk provides a Subject Access Request (SAR) API (POST /api/v1/subjectAccessRequests/exportAll) that exports all data related to a specific contact email across tickets and contacts, supporting GDPR Article 20 data portability rights. For broader GDPR migration guidance, see our GDPR-compliant data migration blueprint. For legal-grade responses, validate scope with counsel rather than assuming the default export is sufficient for every request.

Data Portability Assessment [For CTOs]

Zoho Desk portability rating: Mostly Portable.

Ticket metadata, contacts, accounts, and KB articles can all be cleanly extracted. The main friction points are:

1. Thread/comment extraction requires the API or Data Backup — not the module-level UI export that most users try first.
2. Attachments require secondary API calls to download physical files from secure links.
3. Forum topics are excluded from Data Backup and require separate Community API calls.
4. Configuration data (workflows, blueprints, automations, SLAs) has no bulk export path and must be reconstructed manually or read one API at a time.
5. API credit economics make deep-offset exports increasingly expensive, which constrains throughput for very large datasets.
6. Plan-gated features: UI Export and Data Backup require Professional or Enterprise plans. Free and Standard users are limited to the API.

Zoho's terms do not restrict data export. The real switching cost is engineering time: building scripts to paginate through the API, handle rate limits, download attachments, and transform data for your destination platform. Access is permission-gated: UI export requires the Export Records permission, and Data Backup is restricted to the primary contact. (help.zoho.com)

For organizations with 100K+ tickets, switching typically represents 2–4 weeks of dedicated developer effort — or a budget for a specialized migration service. For architectural comparisons that affect migration complexity, see our Zoho Desk vs Jira Service Management guide.

Timeline and Resourcing for a Full Data Export [For PMs]

These are planning numbers, not vendor SLAs. They are based on Zoho's published export caps, backup behavior, and API credit model.

Phase breakdown for a full API-based export:

1. Scoping (0.5–2 days): Identify objects, custom fields, attachments, relationships, and total volume. Run GET /api/v1/tickets?limit=1 and check the response headers or use UI dashboard counts to estimate total records per module.
2. API setup (0.5–1 day): Register OAuth app, generate tokens, configure data center routing, verify orgId. Test a single request per endpoint.
3. Extraction (3–14 days): Paginate through all objects, handle 429/401/500 errors, download attachments. Credit limits will gate your daily throughput. Use modifiedTime filtering for incremental runs.
4. Validation (1–3 days): Reconcile record counts, spot-check data integrity across tickets/threads/attachments.
5. Cleanup (1–2 days): Fix encoding issues, normalize timestamps, map IDs, resolve orphaned references, enrich lookup fields.

Minimum team: UI export or Data Backup requires no developer. API-based export requires at least one developer experienced with REST APIs and OAuth 2.0. A managed service offloads all of it.

When to Bring in Help

If you are exporting data to migrate away from Zoho Desk, ClonePartner handles the entire extraction programmatically — resolving secure attachment links, reconstructing full conversation threads, mapping custom fields, and working within Zoho Desk's credit-based API limits and concurrency constraints. That matters most when the project is not just "get the rows out," but "preserve the history well enough that the next system can actually use it."