Genesys Cloud - Developer Community!

Hello,

I have written a program which updates IVR object's "DNIS" array with new numbers. Now according to https://developer.genesys.cloud/routing/architect/#put-api-v2-architect-ivrs--ivrId- the rate limit for this operation is 100 operations/minute - but I am now hitting the limit immediately after trying to update 3 IVRs in parallel.

Is there a problem when I fire off these 3 requests in parallel? In other words, how is this rate limit to be interpreted?

• That after firing off 100 requests, the next request can only start after 1 minute?
• Or that I have to space my requests by a delay of (*60 seconds/100*) seconds?

Or is that a current global load problem?

After the "Retry-After" period ran down, I then try to re-run these requests - and get the same error again and again. Lather, rinse and repeat - this is a total blocker here.

The application I am now testing is a JavaScript app which is included as integration into the Genesys Cloud browser UI. The integration is a separate OAuth client, with own clientID, but it runs with the user credentials - so are the requests from the standard Genesys Browser UI maybe interfering with my integration?

There are other integrations, where I also get "429" errors before I could hit the official API rate limits, but this is the most egregious example, because it is (in this case) a total blocking point for my integration.

Wolfgang Liebich

Hi Wolfgang,

Even though your integration has its own distinct OAuth Client ID, the fact that it runs with the user's context is the crucial point regarding rate limiting.

Let's explain why the standard Genesys Cloud browser UI is likely interfering and causing you to hit limits sooner than expected:

1. Layered Rate Limits: Rate limits in Genesys Cloud are applied in multiple layers which you can find the details in this documentation.

   • Resource-Specific Limits: These apply to specific API endpoints or groups (like 100 operations/minute for PUT /api/v2/architect/ivrs/{ivrId}). This limit typically applies per user for calls made to that specific resource, regardless of which OAuth client is used, and is shared. It's very likely you are hitting this limit first in your scenario.
   • Per-Client User Limit (org.app.user.rate.per.minute): This limit defaults to 300 requests/minute. Its meaning is: "The maximum number of requests a user is allowed, per minute, with a specific Authorization Code or Token Implicit OAuth client grant (i.e., your integration's client)." This limit applies specifically to your integration and that user.
   • Overall User Limit (org.user.rate.per.minute): This is a broader limit (default 3000 requests/minute) and caps the total number of requests a user makes via all OAuth clients using Authorization Code/Implicit Grant combined (including the Genesys Cloud UI itself).

2. UI is API-Heavy: The main Genesys Cloud application constantly makes API calls in the background to update presence information, fetch queue stats, check interaction states, load directory contacts, render configuration pages, etc. Every click and automatic refresh often translates to one or more API requests made under the user's context, and these requests consume the Overall User Limit (3000/min).

3. Combined Load and Result: Your integration's API requests are added on top of the potentially significant number of requests already being made by the main UI for that user. Your 3 parallel requests are most likely consuming the resource-specific limit (100/min). While the main UI activity doesn't directly consume your specific client's 300/min limit, it increases the user's overall API activity, which might result in less burst capacity being available for resource-specific limits when your application calls them.

4. In essence: The 429 error you're encountering is most likely due to exceeding the resource-specific 100/min limit for PUT /api/v2/architect/ivrs/{ivrId}. Although your separate Client ID identifies your application, the user token identifies the actor whose limits are being consumed for user-context operations.

This makes the strategies discussed earlier – sequential processing, adding delays between requests, robust Retry-After header handling (with exponential backoff), and investigating the user's total API traffic – absolutely essential for integrations running within the Genesys Cloud UI under user credentials.

Hi, Orhun,

Thank you for your analysis. I will add some clarifications, though:

• I already have a rate limiter in my app. This rate limiter also reacts to "Error 429" by analyzing ths Retry-After header and honoring it.
• In this test, I let the browser collect a HAR file, to see all requests to the API. There were less than 100 requests in total, so I cannot see how I got over that limit.
• Sometimes 2 of the 3 PUT requests fail, but one goes through.
• When the failed requests are retried (after the time specified by Retry-After runs down), often the problem persists - both request immediately get a 429 response, despite there being no other request to any /api/v2/architect/ivrs/{ivrId}resource (according to the HAR file).
  • Is it possible to see something like a "request history"? The "Operational console" does not fully help here, unfortunately.
• I also had cases where, after one or two retries, the requests succeed finally. At another time, though, all retries failed again with 429 - after 7 iterations I aborted the operation then.

In toto, the behavior looks to me like there are way lower "effective" limits at play here, which I cannot see, cannot query, and therefore cannot use.

What I did also see in the HAR file is that there are additional OPTIONS requests before the PUT requests. According to my recherches, this is done by the browser, and part of the CORS specification - I cannot really influcence that.

Are these OPTIONS requests also counted for the API limit? In that case, the real API limit would be 50% of the "official" limit, correct?

- Wolfgang Liebich 

Hi,

A more detailed response: I ran a quick test now and analyzed the HAR-File:

• Between 2025-03-27T23:30:02.316+01:00 and 2025-03-27T23:30:02.546+01:00 (the start time of the first request answered with 429) the HAR-File shows 8 Requests in total.
• 4 of these requests are OPTIONS requests - as I wrote above, I do not know if they are counted for the limits, too.
• The first PUT request in this series of 3 PUTs went through, and took 243 milliseconds.
• The second PUT request was sent in the same second (maybe even the same millisecond). It got a 429 response, after 6297 milliseconds
  • Retry-After was 55 seconds.
• The third PUT request was sent 1 millisecond after the 2nd one, also got a 429 response after 6325 milliseconds
  • Retry-After was also 55 seconds
• My application honored these "Retry-After" timeouts.
• After the timeouts, this time, the retry of the first request went through succesfully.
• More updates to the same IVRs, however, got again a 429 errors, which were (this time) resolveable after the Retry-After timeout
• All in all there were 13 requests to IVR resources, in a time interval of about 3 minutes and 15 seconds. This is rather far away from the "100 requests/minute", unless this rate limit is meant at "between requests to /ivrs/... the app must honor a waiting time of at least 600 milliseconds (60 seconds/100 requests)" - is this the way the rate limit must be interpreted