How to Export More Than 1,000 Zendesk Search Results

Zendesk's search API stops at 1,000 results, full stop. There's a separate endpoint built for exactly this problem — here's how to use it without losing data.

Why your search stops at 1,000 results

The normal Zendesk search endpoint, /api/v2/search.json, is capped at 1,000 results total, full stop — 100 results per page, up to 10 pages, and then nothing more, no matter how many tickets actually match your query. If your query genuinely matches 4,000 tickets, you'll only ever see the first 1,000, and there's no page-11 to ask for.

This isn't a bug or a rate limit you can work around by slowing down — it's a hard ceiling built into that specific endpoint. If you need the full result set, you need a different endpoint entirely.

The export endpoint doesn't have that cap

/api/v2/search/export.json is Zendesk's answer to this exact limitation. It returns the full result set for your query — not capped at 1,000 — and it does so using a cursor instead of page numbers, returning up to 1,000 records per page. It takes filter[type]=ticket to restrict the search to tickets specifically, and it uses the same query syntax as normal search, so a query you've already built and tested against /api/v2/search.json generally carries over unchanged.

In practice that means: swap the endpoint, add the type filter, and replace your page-number loop with a cursor loop that keeps requesting the next page until the API tells you there isn't one. The query syntax itself doesn't need to change.

Three things that will bite you if you skip them

1. The rate limit is shared, not scoped to your export

The export endpoint is rate-limited to roughly 100 requests per minute, and that limit applies account-wide — not per integration, not per export job. A tight polling loop that hammers the endpoint as fast as it'll respond doesn't just slow down your own export; it eats into the same quota any other integration on that Zendesk account is using. If you also run a helpdesk sync or another automation against the same account, a greedy export can starve it. Build in a short sleep between page requests rather than firing the next one immediately.

2. Cursors expire after about an hour

An export cursor is only good for roughly an hour. If your export stalls — a network blip, a script that got killed, a long pause between pages — and you try to resume after that window has passed, the resume attempt simply fails and you have to restart the whole query from page one. Treat cursor resumption as best-effort, not a guarantee: design for finishing within the hour rather than relying on picking up later.

3. Respect Retry-After, don't just retry

If you hit an HTTP 429, the response includes a Retry-After header telling you how long to wait. Honour it rather than retrying immediately — an immediate retry against a rate limit you've already exceeded just extends the throttling and makes the export slower overall, not faster.

A practical technique: bound the query by date

Given the hour-long cursor lifetime, the most reliable pattern is to keep each export run small enough to finish comfortably inside that window, and restartable if it doesn't. Bound your query by a date field — created>=YYYY-MM-DD created<=YYYY-MM-DD, or updated>=, or solved>=, depending on what you're reporting on — so each run covers a finite, known slice of tickets rather than an open-ended query that might take hours to page through. If a run fails partway, you restart just that date slice, not the whole history. Pair the date bound with a short sleep between page requests, and you have an export that's both rate-limit-friendly and safe to re-run.

This behaviour — the 1,000 cap on plain search, the cursor-based export endpoint, its rate limit, and cursor expiry — was verified against Zendesk's own documentation on 18 July 2026.

Where this fits alongside views and Explore

Search and its export endpoint are the right tool when you have a specific, ad hoc question with date bounds or field filters — not a saved operational queue and not an aggregate dashboard. If you're not sure whether a view, a search, or Explore is the better starting point for your reporting need, this comparison walks through when to reach for each. And if the goal is to turn this export into something that refreshes on a recurring schedule rather than something you run by hand, see how to schedule a Zendesk export to Google Sheets.

The shortcut: Zendesk Exporter

Zendesk Exporter is a Google Sheets add-on that runs searches through the export endpoint for you — no 1,000-result cap, no cursor-handling code to write — and can keep a saved search refreshed in a spreadsheet on a schedule. Worth knowing its actual scope: it exports ticket fields, not comment or description bodies; refresh schedules are hourly, daily, or weekly, not monthly; it works against one Zendesk subdomain at a time; and it doesn't export users or organisations. The free tier gives you one saved query with manual refresh; Pro is A$15/month for unlimited saved queries plus hourly, daily, or weekly scheduled refresh.

If you'd rather not write cursor-handling and retry logic by hand, Zendesk Exporter runs your search through the export endpoint for you.

Install from Google Workspace Marketplace See Zendesk Exporter

Last reviewed 25 July 2026.