Zendesk Data Export
There are four ways to run a Zendesk data export and they return different data. Picking the wrong one is how a migration discovers it's missing two years of tickets.
The four Zendesk data export routes
They are not four flavours of the same thing. They cover different records and different fields, and knowing which is which saves a lot of arguing later.
What each one actually includes
The conversation
This is the big one. A CSV export gives you one row per ticket. One row cannot hold a fourteen-message conversation, so it does not: you get the ticket attributes and the first description, and the rest of the thread isn't there. The structured account export formats carry more, and the comments API endpoint carries everything. If someone asks for "all our tickets" and you hand them a CSV, you have handed them the metadata and none of the support.
Attachments
Exports contain references to attachments, not the files. Downloading the actual files means walking the ticket comments over the API and fetching each attachment URL, with authentication, and storing them yourself. On a large account that's a job measured in hours and gigabytes, and it is invariably discovered on the last day of a migration.
Custom fields
Present, but keyed by internal ID or by the field title as it is right now. Rename a field after the export and your mapping breaks. Pull the ticket fields list at the same time as the data and keep them together.
Deleted records
Only the incremental export API tells you that something was deleted. Every other route simply shows you fewer rows than last time, with no explanation. For anything that keeps a copy in sync, this matters enormously.
Satisfaction, SLA and audit history
Ratings and SLA breach data live in their own endpoints and reports. Field-change history lives in ticket audits. None of it's in a standard ticket CSV, so if your reason for exporting is compliance or analysis of how tickets were handled, plan for extra passes.
The archived ticket trap
Zendesk archives tickets that have been closed for long enough, and archived tickets don't behave like live ones. They fall out of views. They behave inconsistently in search. Depending on the route you took, they may simply not be in your export.
The failure is quiet, which is what makes it dangerous. You export, you get a large file, the file looks fine. Nobody counts. Months later someone asks why the historical trend starts in April.
Two defences. First, count before and after: get a total ticket count from the API and compare it against the rows you received, every time, as an automated check rather than a habit. Second, if history matters, use the incremental export API, which reads from the database and includes archived records rather than relying on the index.
If you're pulling everything for a one-off analysis, exporting tickets through the API is more work up front and the only route that lets you prove you got it all.
Choosing by job
A spreadsheet for a meeting tomorrow. View export. Ten seconds, good enough, nobody needs the conversation.
A number for a report. Explore. Do the aggregation where the data is instead of in a pivot table you will rebuild every month.
Feeding a warehouse. Incremental export API on a schedule, with deduplication on ID and a nightly reconciliation count. Nothing else stays correct over time.
Leaving Zendesk, or a compliance request. Full account export plus the API for comments and attachments. Both. The export gives you the breadth, the API gives you the depth, and you need each one to check the other.
A GDPR subject access request. Search by the individual, then pull the tickets, comments and audits for each. Remember they may appear as a CC or a follower rather than a requester, and that side conversations and internal notes are part of the record.
Practical notes before you run one
Full exports can take hours on a large account and arrive as a link with an expiry on it. Start the job before you need it, and not at the same time as somebody else, because the rate limit on account exports is measured in runs per day.
The file will contain customer personal data. It leaves your access controls the moment it lands in a Downloads folder, and it will get emailed to a consultant. Decide where it lives, who can open it and when it gets deleted before you click, not after. Note what you exported and when, too: a second export a week later overlaps the first, and without a timestamp you have two files with no defensible relationship between them.
Frequently asked questions
Does a Zendesk CSV export include ticket comments?
No. A CSV is one row per ticket, so you get the attributes and the first description. Use the structured export formats or the comments API for the full conversation.
Are attachments included in a Zendesk data export?
Only as references. Fetching the actual files means walking ticket comments over the API and downloading each attachment URL with authentication.
Why is my export missing older tickets?
Almost always archiving. Tickets closed for long enough are archived and drop out of views and some export routes. Use the incremental export API to include them.
How often can I run a full account export?
Infrequently. Account exports are limited to a small number of runs per day, so treat them as a planned job rather than something you can retry casually.
What is the best export for a data warehouse?
The incremental export API on a schedule. It reports deletions, has no result ceiling, includes archived tickets and can be reconciled against a count.
Exports show you how many duplicates you have
Group an export by requester and hour and the pairs jump out. Ticket Merger stops them before they reach the export at all.
Start free trial14-day free trial. No credit card required.