Hello everyone,
In ISC SailPoint, there is a rate limit of 100 requests per 10 seconds per access token.
Unfortunately, SailPoint is not willing to increase this limit beyond 100.
Do you think it would be possible to work around this by using two access tokens at the same time?
The idea would be to switch between tokens so that I could effectively make around 200 requests within the same timeframe.
Do you think this approach could work?
Thanks in advance for your thoughts!
Hello @SefaGoevercin,
Welcome to the SailPoint Developer Community!
That’s a great question and a classic rate-limiting puzzle. What is your requirement/use case and how are you planning to call the APIs?
Yes, your proposed approach of using two (or more) access tokens to increase your effective request rate is a common strategy. The rate limit in ISC is applied per access token, so by rotating through multiple tokens, you can achieve a higher throughput.
Here’s how it would work in practice:
Generate multiple Access Tokens for the same client/PAT or user with the necessary permissions.
In your application/script/code, maintain a pool of these tokens.
Distribute your API requests across the tokens. You could use a simple round-robin strategy or switch to the next available token after you’ve made a certain number of requests (e.g., 90-95 requests) with the current one.
However, a word of caution: While this works, it’s often better to first optimize your API calls. Relying on multiple tokens can add complexity.
Before going down that route, I would strongly recommend looking into using ISC’s bulk and search-based APIs to see if you can perform the action required in less API calls.
Using a more efficient endpoints for your use case can reduce the number of individual API calls you need to make, often eliminating the need to work around the rate limit in the first place.
Good luck
Hi Amar,
Thank you for your reply.
My Use Case
I have, for example, 200 roles assigned to me as an identity.
Each task consists of two API requests:
A: GET ${SailpointApiEndpoints.Roles}/${roleId}
B: GET ${SailpointApiEndpoints.Identities}/${personId}/role-assignments/${assignmentId}
Endpoint A does not provide the following fields:
That’s why I need to perform the second request (B) for each role.
This means that for each task, I make two requests. Currently, I process 50 concurrent tasks, then wait 10 seconds before processing the next 50, and so on.
I have implemented a priority queue to respect the API rate limits and to prioritize requests based on user needs or visited pages. However, this is still not sufficient for our requirements.
Regarding the Search API: I’m not sure if it can return all the required fields in a single call. Even if this approach works, I’m also unsure whether newly created roles are indexed quickly enough for our use case.
Regarding Access token and round robin: This approach is definitely a good idea. Thank you for that. If we are going to use this approach, then it needs to be bullet proof and the tokens needs to be taken care very well.
What do you think about my use case ? are there any ways to achieve those properties removeDate and assignmentSource at once ?
Thank you in advance!
Hi @SefaGoevercin,
Thank you for the detailed explanation of your use case.
Your current approach is logical, and fortunately, there is a bit more efficient way to get the removeDate and assignmentSource for all of an identity’s roles at once.
Use the List Role Assignments Endpoint instead of fetching a list of roles and then iterating through each one to get assignment details, you can make a single API call to get everything you need:
Endpoint: GET /v3/identities/{identityId}/role-assignments
Each object in that array contains the role object and the assignment-specific details you need like removeDate and assignmentSource where applicable: -
How This helps?
Making one single call: GET /v3/identities/{identityId}/role-assignments, This endpoint supports pagination, so if an identity has thousands of roles, it might take a few calls, but it’s still drastically fewer API calls.
This change may resolve your rate-limiting issues as well.
Regarding the Search API you are right to be cautious. There can be a slight indexing delay.
Regards,
Amar Sheriff
Hello Amar,
thanks again!
Unfortunately either you are not correct or i do get a wrong output.
I did your request /identities/XXXX/role-assignments
where the X’s is my identity id.
i get an array of roles, thats correct. But they are all populated like this :
...,
{
"id": "-----",
"role": {
"type": "ROLE",
"id": "------",
"name": "----"
}
},
..,
There is no information available here except the name, roleid and the role-assignment-id.
I would appreciate if you could check this within your team. The identity id is an ORG_ADMIN accourding to the user level matrix.
Thank you!
Hi Sefa,
Thanks for trying my suggestion.
Seems like I got excited 
and misread the documentation. You would have to query with either a Role Id or Role Name along with identity Id to get the additional response like below in the endpoint: -
[
{
"id": "<Assignment ID>",
"role": {
"type": "ROLE",
"id": "<Role ID>",
"name": "<Role Name>"
},
"comments": null,
"assignmentSource": "LCM",
"assigner": {
"type": "IDENTITY",
"id": "<Identity ID>",
"name": "<Identity Name>"
},
"assignedDimensions": [],
"assignmentContext": null,
"accountTargets": [
{
"source": {
"type": "SOURCE",
"id": "<Source ID>",
"name": "<Source Name>"
},
"accountInfo": {
"nativeIdentity": "<Native Identity>",
"displayName": "<Display Name>",
"uuid": "<UUID>"
},
"roleName": null
}
],
"removeDate": null
}
]
Not really reducing your API calls and helping with rate-limiting the way I see it as the results are per user-role assignment.
Cheers!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.