Preview API: TaskMangement API will return 429 instead of 409 when daily limit is exceeded

Description

Genesys Cloud will change the error code that we return when the daily limit is reached.

Change Category

API

Change Context

We are making this change to ensure consistency across our platform APIs.

Change Impact

Genesys Cloud will now return 429 error codes instead of 409 error codes in the below scenarios:

  • Client reaches daily limit of workitem creations for organization.
  • Client reaches daily limit of workitem updates for organization.
  • Client reaches the allowed per minute update limit for a workitem.

Date of Change

Immediate

Impacted APIs

POST /api/v2/taskmanagement/workitems/
PATCH /api/v2/taskmanagement/workitems/{workitemId}
POST /api/v2/taskmanagement/workitems/query/jobs

References

[WORKITEMS-2778]

Hello! I have my concerns about this...

For this one I think this is OK...

  • Client reaches the allowed per minute update limit for a workitem.

But... for these daily ones...

  • Client reaches daily limit of workitem creations for organization.
  • Client reaches daily limit of workitem updates for organization.

Many applications have the 429 handling logic configured to retry using the retry-after header. That is even the default behavior of some of the SDKs... Couldn't this be a problem? What is the retry-after value for these cases?

If it is too high (like, until the next day), then the apps could freeze waiting for too long. But if it is short, then it would be retrying pointlessly.

Hi Adrian,

Blockquote Many applications have the 429 handling logic configured to retry using the retry-after header. That is even the default behavior of some of the SDKs... Couldn't this be a problem? What is the retry-after value for these cases?

In daily limit breaches, we return the exact seconds left after which the limit will be offset.
If a user tries to create a workitem at 11:55 PM and the daily limit exceeds, the value of retry-after will be set to 300.
If a user tries to create a workitem at morning 11:55 AM and the daily limit exceeds, the value of retry-after will be set to 43500.

We discussed this internally and decided to go with 429 as if the user tries after some time the request will be successful.

Please let me know if this answers your questions.

Hello Saurav. Yes, that answers my question. I suppose the risk depends on how the retry logic is implemented. For example, digging up the Python and Go SDKs' code (the ones I use the most), it looks like there is a maximum for the time waiting when retrying. I suppose in the other ones you have considered it too. Thank you!