The Zendesk Reporting API
There's no single Zendesk reporting API endpoint that returns your dashboard as JSON. What exists is better for a warehouse and worse for a quick number.
Set expectations first
People search for a reporting API expecting to POST a query and get an aggregate back, the way a BI tool would. Zendesk doesn't work like that, and pretending otherwise wastes a week.
Explore is the reporting product. It has its own query builder, its own datasets and its own scheduled delivery, and it is genuinely good at aggregation. What it isn't is a general query API you can call from your application on demand. Scheduled exports and downloads are the supported way to get Explore output out on a routine.
The Support API, meanwhile, gives you rows. Tickets, users, events, metrics per ticket. Aggregation is your job.
So the honest split is this. Need a number on a dashboard for a human? Build it in Explore. Need data in your own warehouse so you can join it against revenue, product usage or anything Zendesk has never heard of? Pull rows through the API and aggregate there. Trying to do the first job through the API is where people get stuck.
The Zendesk reporting API endpoints worth knowing
Everything else is derived. Agent performance, group volume, channel mix, all of it comes from aggregating these rows yourself. That sounds like a lot of work and it is, once, and then it runs forever and you own the definitions.
Incremental exports are the backbone
For anything that keeps data in sync, this is the endpoint family that matters.
GET /api/v2/incremental/tickets.json?start_time=1767225600You pass a Unix timestamp and get back records changed since then, a thousand at a time, with a cursor to continue. It reads from the database rather than the search index, so there is no lag and no result ceiling, it includes archived tickets, and it tells you about deletions. Search does none of those things.
Three details that bite.
The broader comparison of export routes, including full account exports and view exports, is in the Zendesk data export guide.
Building something that stays correct
A reporting pipeline that survives contact with a real account looks roughly the same everywhere.
Pull incrementally on a schedule, upsert into your own store keyed on ticket ID, keep the raw JSON as well as your parsed columns, and record the high water mark you reached so a failed run resumes rather than restarts. Then aggregate in your warehouse, where you can version the definitions.
Reconcile. Take a count from the API and compare it against your row count, automatically, every run. Silent drift is the characteristic failure of this kind of pipeline, and it's always discovered by somebody asking why a number looks small rather than by an alert.
And handle deletes explicitly. Incremental exports report them. If you ignore that, your historical numbers slowly diverge from what Zendesk would tell you, and reconciling a year later is genuinely painful.
Definitions are the hard part, not the API
Once the data is out, the arguments start. What counts as first reply time when the first response was an autoresponder? Does a ticket reopened after three weeks reset resolution time or extend it? Are business hours applied, and whose?
Zendesk has answers baked into its own metrics, and yours may differ. That's fine, and it's why row-level data is valuable, but write the definitions down. A dashboard that disagrees with Explore by 8% is not a bug, it is two reasonable definitions, and nobody can tell which without documentation.
One easy sanity check: reproduce a single Explore number in your pipeline before you build twenty of them. If you can match one exactly, your extraction is sound and any later disagreement is a definition question.
Frequently asked questions
Is there a metrics endpoint for tickets?
Yes. The Zendesk ticket metrics API returns per-ticket durations like first reply and full resolution time, and it's the closest thing to a Zendesk metrics API. For history at scale, Zendesk incremental export is the endpoint to build on.
Is there a Zendesk Explore API for running reports?
Not as a general on-demand query endpoint. Explore is built for its own query builder and scheduled delivery. For programmatic access, pull row-level data through the Support API and aggregate yourself.
How do I get first reply time programmatically?
From the ticket metrics endpoints, which carry per-ticket time and count measurements, or by deriving it yourself from ticket audits if you need a different definition.
What's the best way to keep a warehouse in sync?
Incremental exports on a schedule, upserted on ticket ID, with a stored high water mark, deduplication on the inclusive start time, and an automated count reconciliation.
Why does my number disagree with Explore?
Almost always a definition difference: business hours, reopened tickets, or what counts as a first reply. Reproduce one Explore figure exactly before trusting the rest.
Can I get CSAT scores over the API?
Yes. Satisfaction ratings are their own resource, with scores and comments, rather than being a field on the ticket.
Duplicates inflate every number you report
Ticket Merger merges duplicate Zendesk tickets on requester, subject keywords and ticket fields within a time window, so your volume figures describe real problems.
Start free trial14-day free trial. No credit card required.