Search API Delayed Results vs Users API


  • Peter Hochstrasser

    Hi Chuck P

    Please keep in mind what happens when you save a change to a user: First, the actual user record is saved, and then, the changed user record is submitted to the federated fulltext search. This works much like other federated searches; it is not real time, but usually pretty quick. Excuse the soft time frames - the execution speed depends not only on your activity, but may encompass the loads of all of your pod's instances.

    You see the same behaviour if you change a Light Agent to become a "real" Agent, and then try to assign tickets to him: You will also need to wait a few ... minutes, I'd say, so, the behaviour you see is both explainable and to be expected.

    To your questions:

    • The API behaves as is to be expected.
    • This is an architecture-inherent property and cannot be changed lightly.
    • Is there a quicker way? Not without a bit of tweaking:
      If you use the user endpoint and side-load the user's tickets, this may be more up to date - but I can't say for sure.
  • Greg Katechis
    Zendesk Developer Advocacy

    Hi Chuck! Delays in querying via the Search APIs are expected, up to a couple of minutes, as we note here. The underlying reasons are due to the nature of search...all data must first be indexed before it can become searchable. In addition to the time it takes to index the data, we also have multiple hosts that will be utilized (I believe that we may have up to three hosts, but don't quote this as canon), so if your request is routed through a host that has not yet been indexed, it can be delayed further. So generally speaking, indexing can take about a minute, but with the possibility of additional hosts, it can take a couple of minutes.

    Please note that the teams that own the search functionality are constantly looking for ways to improve the service, so what is true today may not be true in the future. However, search indexing delays are an inevitability of how search works in general at this time.

    With respect to other options Peter is correct that side-loading is the place that we would look for a solution, although we do not have a side-load available for what you are looking for. We always appreciate a developer trying to reduce the number of API calls, so thank you for taking the time to research this! When I was looking at the first API call that you noted, this looks to be an efficient way to get the most recently updated tickets assigned to a user. Just so that I understand and can see if there are other solutions, what situations would you need to make multiple API calls for with this request? 

  • Chuck P

    Thanks for your responses, this gives me a better idea of what is and isn't possible with search API.

    We've tested the user API as an alternative way to fetch assigned ticket data without the indexing delays that were mentioned, so we know this method works. 

    What was nice about the search API is that we were able to fetch relevant data pertaining to a ticket all at once.  However, I think our current problem is that we would like a way to be able fetch a user's assigned tickets and include/side-load user identity data as well (eg requestor's primary email, and phone number).

    My initial thinking is that we would first have to fetch all of the user's assigned tickets, then process an API request for user identities for each ticket. 

    Please correct me if I'm wrong, but it seems that this isn't currently possible with a single API request (search API, users API, or ticketing API)? 

    If you have any other suggestions, we are open to any other ideas you might have.


Please sign in to leave a comment.

Powered by Zendesk