I’m currently working on a project for one of our customers to extract all active work reassignment configurations from their ISC tenant. However, I’ve run into some limitations with the available APIs that make this inefficient for large-scale tenants (e.g., over 100k identities).
Key Issues Encountered:
-
No Pagination Support: The endpoints /v2025/reassignment-configurations and /v2024/reassignment-configurations do not support pagination. They return a single response.
-
Incomplete Data in Responses: For users with multiple reassignment types (e.g., both CERTIFICATIONS and ACCESS_REQUESTS), the API only returns details for one configuration type in the configDetails array, rather than all active ones. (Note: I’m unsure if this is due to a single-page limitation or a structural issue.)
-
Legacy and Beta Limitations:
-
The v3 API lacks this endpoint entirely.
-
The /beta/reassignment-configurations endpoint does offer pagination, but it’s currently broken and exhibits the same single-type response issue as v2024/v2025.
-
Current Approach and Pain Points:
As a workaround, my script lists all identities via the paginated /v2025/identities endpoint (with limit=250 and incremental offsets) and then makes individual calls to /v2025/reassignment-configurations/{identityId} for each one. This works for small datasets but generates over 100k API calls in our environment, leading to:
-
Rate limiting (429 errors, even with retries and reduced thread pool size to 5 workers).
-
Long execution times (hours+ for full runs).
-
High risk of token expiration mid-process.
I’ve implemented basic retries with Retry-After header parsing and error handling, but it’s not scalable.
Is there a better way to filter identities upfront (e.g., via search queries for only those with active reassignments) to reduce calls?
Any recommended workarounds?
I’d appreciate any insights, code snippets, or links to relevant docs/discussions.
Thanks in advance for your help
