We’re excited to announce the release of SailPoint API v2026, scheduled for 2026-03-24T04:00:00Z! This version introduces new capabilities and transitions key APIs from experimental to public production status.
We encourage users of our APIs to upgrade to v2026 anywhere they call SailPoint APIs, such as in Workflows, custom scripts and applications, Postman, etc. For more information on SailPoint’s API versioning, including support and deprecation timelines for older versions of our APIs, please see this document:
Experimental APIs
The following APIs have been introduced as experimental.
Tenant Context
The purpose of this API is to manage key-value pairs specific to a tenant’s context, enabling dynamic configuration and personalized settings per tenant. Context key-value pairs will consist of common terms and acronyms used within your organization.
Use this API to retrieve metrics about an org’s API usage. With this functionality in place, administrators can monitor API usage within a specified timespan, as well as a breakdown of commonly-used APIs sorted by number of requests.
We are committed to rapidly evolving our APIs to deliver stable, reliable, and production-ready endpoints that our customers can depend on. By closely monitoring adoption and feedback, we ensure that experimental APIs mature quickly and meet enterprise-grade standards. The following APIs have successfully transitioned from experimental to public production status:
The Parameter Storage is SailPoint’s centralized repository for authentication, authorization, and connection configurations, stored as typed Parameters.
The APIs can be used to input Parameters, which can then be referenced by other services, such as Workflow configurations.
The SSF Transmitter Service is a security event notification system that monitors identity attribute changes and automatically triggers session revocation events when specific lifecycle conditions are met.
Very exciting - can there be some push to review APIs still marked as experimental all the way back to 2024 & 2025? It feels like that’s not right anymore.
Will these new v2026 APIs display consistent behavior?
For the v2025 APIs this is not the case. For example:
Take one of these object types: roles/workflows/custom user levels/access request approvals/work-items
Suppose I want to list all objects of those types, whose owner has id 1234abcd1234abcd1234abcd1234abcd. I would need to call the list API with the following url parameter:
Most API’s behave like this. I suggest this to be applied to the others
ownerId=“1234abcd1234abcd1234abcd1234abcd”
Can’t add it in filters (perhaps combining it with AND/OR filtering) must use it direct as parameter, in camelCase
owner-id=“1234abcd1234abcd1234abcd1234abcd”
Can’t add it in filters (perhaps combining it with AND/OR filtering) must use it direct as parameter, in kebab-case
filters=owner co Tom.Cole
Can’t filter on id, only on name in contains mode. So this example also matches Tom.Coleman
unsupported
Can’t filter on owner, even though this object type has an owner
(Here I have given the different behavior in random order. It can’t be immediately seen which object types I listed above they relate to. Ideally all these APIs display the same behavior, meaning we can filter on owner in the same way.)
Other examples of inconsistency exists as well:
owner v.s. ownerRef v.s. ownerId
Where the value owner.name comes from (uid v.s. displayname v.s. something else)
How pagination works
enabled: true v.s. disabled:false
launchers have owners but they can’t be updated due to the API limitations. We have owners who left the organization who are still owner of these objects.
Since v2024, this new way of API versioning should make it easy to fix inconsistencies among the APIs. I have not seen the fixes in v2025. I hope the inconsistencies will be fixed in the v2026 APIs, and that new APIs are being tested to this consistent behavior, as I notice that new APIs are also not always consistent to what we would expect based on the already existing APIs.
This API is already deprecated according to the warning notification seen on that page, despite being v2025. It mentions to use the new one at get-access-request-config | SailPoint Developer Community
But that one is also mentioning that it is deprecated, linking to itself as alternative.
I tried the v2026 API on a nonproduction tenant, and got the error that the experimental header is missing. So the production API seems to be deprecated and replaced by a non-production API.
On another note, perhaps it would be good for the “Experimental Header is missing or invalid.” message to also directly display the specific header it is expecting, allowing us to immediately copy paste it instead of searching for it in online documentation or somewhere else in our bruno/postman/…
I see that the deprecation message of the /v2026 API is now removed correctly, but the API itself still expects the experimental header, which is not documented. Since the /v2025 production API is deprecated, shouldn’t its replacement also be a production API?
Yes, that will definitely be an improvement, thanks!
What about this post, regarding inconsistencies amongst API’s, have these been fixed in the /v2026 versions?
SailPoint is evaluating a significant change to how its Identity Security Cloud (ISC) REST APIs are versioned. The current annual release model has served as a foundational structure, but as our platform and community have grown, several meaningful pain points have emerged — both for our own development teams and for the customers and partners who build on our APIs every day.
Please take some time to read through this post and then take the survey linked within. It’s important and will impact how this change is implemented.
We need your feedback!