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




  • Avatar
    Jake Holman

    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

  • Avatar
    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. 

  • Avatar
    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.

  • Avatar
    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.

  • Avatar
    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.


  • Avatar
    Jake Holman

    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

  • Avatar
    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?)


  • Avatar
    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.



  • Avatar
    Kunal Parikh

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

  • Avatar
    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...

  • Avatar
    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



  • Avatar
    Steven Yan

    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:

Post is closed for comments.

Powered by Zendesk