Best practices for avoiding rate limiting

Have more questions? Submit a request

21 Comments

  • mayama takeshi
    Comment actions Permalink

    Hello, is the limit controlled by subdomain or by origin IP address? I am asking because I am planning to develop a system to make API requests on behalf of different zendesk subdomains. So the API requests would originate from the same IP address and I would like to know if I should expect problems with this.

    0
  • Sean Kinney
    Comment actions Permalink

    **@Mayama:** The rate limits are on a subdomain basis not based on IP address.

    0
  • Mihai
    Comment actions Permalink

    Does the rate of 200 rpm also apply to the Sandbox instance of main Zendesk instance?

    0
  • Maxime
    Comment actions Permalink

    Yes Mihai, it does.

    0
  • Darren
    Comment actions Permalink

    We're trying to add the "Help" knowledge base widget to our website but always see  429 too many requests. Could that be due to this?

    0
  • Bryan - Community Manager
    Comment actions Permalink

    Hi Darren. Just adding the web widget would typically not put you over the top of your API limits. I would also check for other integrations or apps that might be calling Zendesk APIs and look there.

    If there's another script or web app that's making API calls, it could be putting you over your limit. If that's the case, then following the practices of this article may help.

    If it's still not clear what may be putting you over your limit, then sending in a ticket to support@zendesk.com can get you more help specific to your environment. Hope this helps!

    0
  • Russell Dunn
    Comment actions Permalink

    Are there any plans to revisit these limits? The user limit seems rather low.

    We're on enterprise support and are limited to 700/minute when using auth tokens, but have an app that runs for the logged in user, which is getting throttled as it makes a large number of individual requests. It processes batches of tickets so there's no real way to limit this.

    0
  • Bryan - Community Manager
    Comment actions Permalink

    Hello Russell Dunn -- there have been no announced plans to change the current limits. There is the "High Volume API" add-on for situations where a higher rate limit is needed. Typically rate limit conversations are unique to particular needs and the discussion is directed to the account executive.

    Depending on the use-case, sometimes there are alternative approaches that could avoid hitting a rate limit -- more details would be needed if you want to discuss that possibility (what the requests are, what the batches consist of, etc).

    0
  • Karen D Snyder
    Comment actions Permalink

    I would like to test that code that I am writing to handle the 429 response actually works. I guess the only way to test it would be to somehow send enough requests to run into the limit?

    0
  • Dwight Bussman
    Comment actions Permalink

    Hi Karen,

    The easiest rate-limit to hit would likely be the Incremental Exports endpoints, as they're limited to 10 requests per minute.

    Otherwise, rapid-fire updates to a single-ticket can do this pretty quickly as well (making a trigger that points to  a target to update a specific ticket in a loop could hit this limit fast).

    Hopefully that helps for your testing!

    0
  • Jason Taylor
    Comment actions Permalink

    Hi

    I can't seem to find any documentation regarding rate limits for anonymous requests via the requests end-point.

    We're on an enterprise plan so should have 700/min limit (and the header response supports this) - however it seems we're getting a response of;

    {"error":"APIRateLimitExceeded","description":"Rate limit for creating new tickets reached, please wait before submitting more tickets"}

    Long before we hit this limit when using the requests endpoint. The header itself still indicates plenty of capacity (e.g. 698 of 700 left).

    Any idea what's going on?

    Cheers

    0
  • Dwight Bussman
    Comment actions Permalink

    Hi Jason Taylor

    The rate-limit of 700/min is for authenticated requests to that endpoint. If you're hitting a much lower rate-limit, I suspect you may be running into the anonymous (un-authenticated) requests limit. Because this is a common vector for spammers to abuse our platform, we set a lower rate-limit for such anonymous requests based on the IP address from which they originate. 

    If this still doesn't explain what you're seeing, please reach out to our support team to take a closer look.

    0
  • Jason Taylor
    Comment actions Permalink

    Hey Dwight

    Thanks for the speedy reply. I figured that may be the case - and a totally understandable restriction! As a suggestion, it might be worth highlighting that there are lower limits for anonymous requests as it wasn't something that came up during our discovery phase unfortunately. 

    My follow on question from here is; what is the material difference when authenticating and creating new tickets via the requests end-point vs. the tickets end-point? Ideally we'd like to continue using requests as that is what we've built, but if there are significant benefits to using tickets then I would like to understand what they are. 

    J

    0
  • Dwight Bussman
    Comment actions Permalink

    HeyO Jason,

    Definitely a good piece of feedback. I believe our Abuse team has tried to avoid publishing the specific limits for these anonymous requests to avoid broadcasting to spammers just how hard they can hit us, but calling out that "The limits for anonymous requests are substantially lower than those for authenticated requests" seems safe enough to me. I'll pass that along to our Docs team for review.

    The largest differences between those two endpoints are these:

    • Actions taken from the tickets endpoint have a "current user" value of the agent whose credentials authenticated the request (even superseding an author value which might make such updates appear to come from an end-user). This has workflow ramifications, as triggers/automations/SLAs/system-processes/etc. may behave differently depending on whether the updater is an agent or an end-user. Case in point: https://support.zendesk.com/hc/en-us/articles/360019405434-Why-is-the-customer-s-reply-not-changing-the-ticket-status-to-open- 

    • Because the tickets endpoint is only accessible to agents, it can be used to update agent-only ticket-fields (and tags). The requests endpoint is from an end-user perspective, so it's limited to the fields they're able to edit.

    Please let me know if this helps to clear things up! 

    0
  • Jason Taylor
    Comment actions Permalink

    Yes, that really helped and has cleared things up! We're proceeding to testing with creating tickets via the requests endpoint using token auth. 

    Thanks for your support on this Dwight. Much appreciated. 

    0
  • Jason Taylor
    Comment actions Permalink

    One additional question in fact, that I couldn't see an answer to in documentation;

    What happens when the rate limit is reached?

    The request isn't processed and a response is sent containing a 429 response code and a Retry-After header. The header specifies the time in seconds that you must wait before you can try the request again.
     
    Do we know what the retry-after period is when using the requests endpoint with authentication? Trying to gauge the impact here e.g. are we locked out of creating new requests for a minute or an hour? That will impact how we handle hitting the limit I think.
    0
  • Dwight Bussman
    Comment actions Permalink

    HeyO Jason,

    I believe the rate-limit for authenticated calls to the requests endpoint just pulls from the normal pool of requests as documented here. I did some testing this morning and found this to be the case:

    Please feel free to reach out to Support if you're seeing otherwise or have questions specific to your account!

    0
  • Jason Taylor
    Comment actions Permalink

    Got it - what I'm seeking to understand is if we breach this limit, what is the expected behaviour? Are we prevented from accessing the API for a time limit - if so, how long? Is this time limit fixed or is it variable?

     

    0
  • Dwight Bussman
    Comment actions Permalink

    Ope! Sorry - forgot to address that portion of your earlier post.

    The expected behavior is that any other request to the Support API would receive a 429 as you mentioned. That retry_after value should be 60s from whenever the last request was made. This is not to the end of the current minute, but certainly within 2 minutes assuming there isn't a deluge of incoming requests.

    1
  • Josh Lowery
    Comment actions Permalink

    Is there a difference in the rate limit of the search vs the export API?

    0
  • Dwight Bussman
    Comment actions Permalink

    HeyO Josh Lowery

    The standard Search endpoint is subject to the account-wide rate-limit documented here which varies depending on plan-level.

    The Search export endpoint is subject to a limit of 100 requests per minute per account:

    0

Please sign in to leave a comment.

Powered by Zendesk