This is reasonable
I think it is reasonable to have some kind of API call limitation, if done properly.
After all, API calls cost electricity, server space, server time and money. If a customer uses highly inefficient algorithms, or calling functionality requiring many API calls unnecessarily often, this will have a huge cost on resources, which will negatively impact SailPoint. In order to stimulate taking API call frequency into account when designing algorithms, it should be reasonable to have some kind of limitations.
However, the focus lies here on “if done properly”.
Clear announcements
This would include active announcements on this change as mentioned by @sup3rmark. SailPoint makes big announcements when it comes to added/enhanced functionality, but it is just as important, or maybe even more important to make announcements when introducing deprecations, blockers or limitations. Since this will have a negative impact if the customer/partner is not aware of this, especially if they are not aware of this on time.
Offer efficient alternatives
It also puts a reasonable responsibility on SailPoint to facilitate having efficient algorithms. If we have 250 governance groups, each of which with roughly 5 members. Then we would have 250*5=1250 mappings in total. And we need to get a report of all governance groups and its members. We currently have to use 1 API call to get 250 governance groups, and then use 250 API calls to get the members. So we make 251 calls to get the 1250 mappings. If SailPoint would have a decent governance-groups-to-member-mapping API that supports standard 250-object pagination on it, we could just call 5 API’s to get all the data. Another example: Please give us the option to efficiently use API calls to get all roles that point to at least one entitlement of a given source. One example where using search API is allowed and one where it is not. Note that the search API has a 24 hour SLA, so is not trustworthy for use cases requiring real-time information.
Penalizing improvements
If you use SailPoint’s out of the box access request reminder and escalation functionality, you might get more escalations than what you would like and the reminders will not specify that they are actually reminders. It just sends the same message. We have an alternative, where we turn off this functionality, and instead use a workflow to achieve the same thing, but then in a desired manner which is even more efficient. But due to the introduced limitation of API calls and active workflows, this is now less desired to use.
Limitations in workflows
Synchronous Recursion is not allowed within one workflow execution. As a consequence SailPoint suggests using full workflow execution recursion as best practice. But this requires the workflow to use an external trigger. So for any other workflow that does not have an external trigger, it now requires a second workflow to perform the recursion. As such you need two workflows for 1 bit of functionality. This means more API calls to trigger the child, and you reach the max workflow limit twice as fast each time you need to apply this trick.
API calls in workflows
APIs have been build for API clients to call Identity Security Cloud. But workflows are defined in Identity Security Cloud itself. It is basically a script running on the tenant. This communication should be way more efficient and low-cost as compared to running constant calls over the internet. As such, there should be a more efficient way in workflows to get information within the same tenant. As such, counting internal API calls made within a workflow execution should not be counted.
API calls made by UI
The UI is also making API calls to Identity Security Cloud. Are these API calls getting counted? The UI is making some quite inefficient number of API calls. For example, If you remove a segment from an role/access-profile/entitlement, the identities in that segment will not be able to request that object anymore, except when it was the last segment you removed from that access object, because then everyone is able to request it. To tackle this design and support least privilege you can have a segment with no identities refer to all objects at all times (where a workflow can manage this). But if you now want to open this segment in the UI, it will first call APIs to get all the pages of all the mapped access objects, even though the UI will then only show one page afterwards. Thigh highly inefficient waste of API calls, will they be added to the API limit? Examples like this would make it less desirable to use the out of the box SailPoint UI, since it would then be slurping away the limit threshold. Other segments with many objects assigned will also call unnecessarily many API calls. I reported this issue to SailPoint when segments was introduced, but it still exists.
Unfair limitations
As mentioned by others. These limits are not based on number of identities. But if a workflow is triggered on a mover flow. Naturally it will trigger more often with more identities and thus make more API calls. It would be reasonable if a component of the API limitation scales linearly with number of identities. After all license costs also partially scale linearly with identity count if I am not mistaken.
API calls getting counted multiple times?
There is a rate limit of how many API calls you can call in a timeframe of 10 seconds per Personal Access Token. I once created a new PAT, and tested this limit, but sometimes I noticed the 429 errors before I actually send 100 API calls (taking into account the original OAuth authentication). I wonder if some API calls do under the hood at server side trigger other API calls, which will then also get added to this API call. If this is the case, some API calls basically are counted twice.
Workflows with more than 100 steps?
It is not allowed to have only 1 workflow, but which contains more than 100 steps? I don’t have an immediate example available, but I can imagine cases where it is required to have more than 100 steps, especially given some of the limitations that workflows currently has.
Unauthenticated API calls?
What about unauthorized (malicious?) people/agents calling our endpoints without authentication or authorization. Will those API calls be included in the metrics?
Loopback connector
What about the SailPoint out of the box loopback connector? According to the documentation, it does not support delta aggregation. And since there are no identity-user_level mapping or identity-governance_group-membership APIs, it calls at least one API per identity right? These inefficient algorithms that SailPoint currently offers will also add to the API counter more than necessary.
Hard stop on surpassing API limitation?
Like others mentioned. There needs to be a clearly defined process on what happens if this limitation is being exceeded.
limits on number of entitlements
Large (international) organizations will have many applications, but these applications might also have many entitlements, especially if you have a different entitlement per country. I can imagine this having a multiplicative effect, so I wonder if the limitation of entitlements is reasonable. Also keep into account that there is an even stronger limitation when it comes to working with backups in SailPoint.
Summary
So it makes sense that there are reasonable limitations on API usage since reasonable number of reasonable algorithms should not result in customers exceeding such limits, but this can only be done properly if SailPoint also supports this by offering proper APIs that make it possible to utilize implementing reasonably efficient algorithms and by taking into account reasonable arguments resulting in higher API calls that should not be counted. In my opinion, SailPoint, customers and partners have a shared responsibility to prevent unnecessary amount of internet-traffic and server calculations, as this will decrease costs and benefits us all. A silent announcement introducing a hard limit without addressing the nuances and required changes within SailPoint’s API offerings will not be beneficial to this shared goal.
Kind regards,
Angelo
