We are developing a SCIM 2.0 compliant service and are preparing to integrate with Okta as an identity provider for our customers. To ensure we can build a robust and scalable solution, we need to understand the specific request patterns of the Okta SCIM client, particularly for scenarios involving a large number of users (e.g., thousands).
Our primary questions are about the expected request load for different SCIM operations:
1. Initial Bulk Synchronization / Onboarding:
- When a customer onboards and assigns our SCIM application to a group in Okta containing several thousand users, at what rate will the Okta SCIM client send requests to our server?
- How are these requests typically distributed across our SCIM endpoints? For example, what is the expected rate of
POST /Usersrequests? - Does the client send requests sequentially or in parallel? If in parallel, what is the typical level of concurrency we should expect?
2. Bulk Deactivation / Deletion:
- Similarly, if an administrator unassigns a large number of users from our application (or if users are deleted), what is the expected request rate for
PATCHrequests (to setactivetofalse) orDELETE /Users/{id}requests? - How does Okta handle the deletion of a group with a large membership? Will it trigger individual requests for each user, and if so, at what rate?
3. Client-Side Throttling and Retry Logic:
- If our server responds with a
429 Too Many Requestsstatus code and includes aRetry-Afterheader, what is the precise behavior of the Okta SCIM client? - Will it pause all provisioning activities for the duration specified in the
Retry-Afterheader for that specific customer? - In the case of throttling during a large group membership update, will the client retry only the failed requests, or will it re-synchronize the entire group membership?