Understanding SCIM Client Request Behavior and Expected Load for Large-Scale Operations

Questions SCIM
1

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 /Users requests?
  • 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 PATCH requests (to set active to false) or DELETE /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 Requests status code and includes a Retry-After header, what is the precise behavior of the Okta SCIM client?
  • Will it pause all provisioning activities for the duration specified in the Retry-After header 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?