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.

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.

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