In various environments with a large user base where provisioning was used for user assignments and group push, provisioning operations may exceed the vendor's rate limits, causing the application provisioning connector to throw an error. This error follows the standards for the HTTP 429 Error, with the message:
Rate Limit Exceeded
This means the application will not accept any further requests until the cooldown period for the rate limits is over.
This article briefly describes scenarios where provisioning will fail due to the rate limits reported by the external application and how to avoid hitting rate limits on the application side.
- API
- Rate Limit
- Integrated applications in Okta that support provisioning
- Okta Classic Engine
When assigning a large set of users or group push operations that involve updating memberships for many users, consider using RAW API Calls instead of the standard User Interface if assigning through the User Interface is not a feasible option (Example: Pushing multiple Groups will trigger the rate limit).
Using an API platform like Postman or custom scripts allows for implementing delays (added time between requests) for the specific operation that needs to be executed.
That will prevent rate limits from being reached and allow the operation to be completed successfully without any downtime.
Also worth noting here is rate limits specific to a certain application are listed publicly and can be accessed upon implementing the solution mentioned above (see this Slack example).
Comparing the count of provisioning operations and knowing the vendor rate limits will offer a general overview before any change in the environment is executed.
