Forums/Community/Zendesk API


REST API search.xml limited to 15 records at a time?

Vic Thomas
asked this on September 24, 2009 13:41

I would like to be able to use the REST API to pull ticket data into a report writing tool that works nicely with XML.  The problem is, the API limits the number of tickets to 15 per GET.  The URI that I am using is

Is there a way to ask for all records in one request/response cycle?  Having to iteratively add "&page=2", "&page=3", etc. to the URI to compose the full view of all tickets would dramatically complicate matters.




User photo
Jake Holman
Product Manager

Hi Vic,

Searching via the API will limit all result to 15 per page, and unfortunately this is not likely to change. The reason we do this is to simply limit the amount of time it would take to compute all of the results, if you could imagine a very busy website using the API in an auto-complete scenario, for example, could you imagine the amount of data being passed over if the code makes a search on every keyDown event?

You will need to ensure your application is searching more specifically, or can iterate over the page results. 

Alternatively, if you just want to get all Ticket data, you could consider using the Tickets API:

Jake Holman
Zendesk Support

October 19, 2009 03:54
User photo
Vic Thomas

Hi Jake,

Thank you for your response.  What I need is simply a read-only view of our ticket data that I would pull maybe once per week, in an automated reporting tool.  Imagine something analogous to an SQL SELECT statement.  Ideally, I would be able to reduce the amount of unnecessary data pulled from ZenDesk by choosing only a small set of ticket fields and by applying a filter in the API request.  But, I can accept working with the entire set of tickets with all their fields, if necessary.  I have no need for updating our data via the API or for dynamic searching based on user interface events.

I don't see anything in the Tickets API that would enable me to get past the 15-tickets per request limitation.  Yes, I can write logic to get around this limitation, but it would cause me a lot more effort than would otherwise be necessary. 

October 26, 2009 08:53
User photo
Neil Lillemark


We too have a separate tool for which we want to query this data to generate some reports.  We also see this as quite a nuisance.  In theory, if your ticket counts and user counts are small, this isn't a big concern - which is probably where most of your customers sit.  But for those of us with hundreds of potential users, and thousands of potential tickets (eventually), the need to iterate over pages is highly inefficient.  The data should be retrievable in one query. 

I can understand your concern of load on your servers, but realistically, we, like Vic would not be running these types of queries all that often.  Besides, the idea of 15 per page is overly small for such purposes, since they are typically different than the page load process you are focusing on with the GUI.  With these thoughts in mind, I think your load concerns are perhaps overstated and you should be able to come up with a provisioning rule that doesn't over-burden your servers.  I suggest you let a few customers trial this and see what the impacts on your throughput actually would be before you throw out the idea of making changes here.

December 10, 2009 10:45
User photo
Jeff McDonald

I agree emphatically that the API needs a non-paginated result set. The API should not be treated like an end-user in my humble opinion. I do get that some will abuse this, but that seems like more of an opportunity for innovation (account-based quotas, bigger clusters, throttling, etc) than a show-stopper. REST APIs based on the .erb views are almost like scaffolding in Rails 1.0. 

Pretty please.

December 17, 2009 14:11
User photo
Vincent Brendel

In case it matters, I'll add one as well. Pagination is for humans.

Saying that you only want to generate 15 items at a time on the server side creates a false economy. Yes, it may be quicker to generate the individual requests, but most systems need all the data anyway and then need to do multiple requests to get what they need. On the server end you then need to do a lot of repeat effort to generate the partial results and on the client end, apart from more complex code, you suffer the extra latency by having to go back and forth.


December 21, 2009 02:29
User photo
Jake Holman
Product Manager

Hi Guys,

Thanks for all the input so far. I just wanted to cut in. 

I'm sure a lot of you all have a fair amount of tickets and end-users in your accounts, and I understand the annoyance of having to iterate through the results of a search. However, dumping all the results on one page isn't going to help anyone if the account has 8k Tickets and 4 Million Users to potentially search through and present. 

Would a better solution for you guys be an increased number of results combined with a page number, and total pages or results indicated in the returned XML/JSON? This means you at least don't have to play a guessing game when iterating through.

Also, if anyone has any example of API's that do not use pagination in their search results, it would be great to see.

Jake Holman
Zendesk Support

December 21, 2009 02:42
User photo
Vincent Brendel
  • Yes, it would be nice to be able to query the number of results that would be returned
  • Rather than increase the number of results per page arbitrarily, it would be better to have the caller specify the desired number of results per page (I suppose an 'all results' option would still be out of the question?)


December 21, 2009 03:30
User photo
Jeff McDonald

Just a pre-note, none of this is critical for me. It is a nice to have. I think you guys are great.

I'd prefer a global cap based on # of admins or account type. x-thousand objects / day consumed. I recognize the complexity/controversy around that and welcome flames/feedback. This would help my company self-throttle our stream.

Another option would be to have a daily delta set cached per organization a la couch db, etc, with an api call/set wrapped around this. Lets users handle the automation of pulling in their customized dailies, and allows just one call. Our group runs internal reports nightly, and currently without the fully automated dump (see my other request :0), full API calls are still our only option.



December 21, 2009 07:19
User photo
Kunal Parikh

@JakeHolman Any updates on returning more that 15 result for searching via the API?

January 28, 2010 20:05
User photo
William Kirby
I have been working with the API for a limited period, specifically for an in-house dashboard for our Opps department. What I am attempting to do is return a count of tickets logged in the previous quarter. Obviously this is greater than 15 and my limited experience/skills makes this task particularly long winded. Is there an easy way to achieve this? Currently I count search results for the current quarter, count search results for the previous quarter and subtract the current quarter from the the previous quarter to get my result? Search string is, e.g. created>2009-10-01 etc...
February 15, 2010 04:38
User photo
Kraig Lockwood

William, I do this using a view.


In Zendesk I have the view showing closed where create time is less than 168 hours, which gives me the last 7 days.


Then for my reporting I use a little php:


//Get tickets from the view

$xmlstr = get_closed_tickets();
$xml = new SimpleXMLElement($xmlstr);


//Get the total number of tickets

$total_tickets = $xml[count];

//Figure out how many pages that is
$pages = ($total_tickets/30)+1;


//Get ticket data for each page of results

for($i=1;$i <= $pages;$i++){


here I pull whatever data I need from each ticket



August 20, 2010 14:43
User photo
Steven Yan
Product Manager
Check Answer

Hi everyone, please see our new developer documentation and new API, which includes collection size of up to 100 per page and consistent pagination parameters:

April 26, 2012 14:28