I am thrilled to introduce the new /latest endpoint, now available!
What’s the big deal?
Simplify version management by using /latest in your API paths (e.g., /latest/accounts instead of /v2025/accounts). Your integration will automatically reference the current annual version across all endpoints, reducing the frequency of version related code updates as new releases become available. While periodic version awareness and updates may still be necessary for major changes, the /latest path minimizes routine maintenance overhead.
Perfect for:
Dev and testing environments where you want cutting-edge features
Scripts and automations that don’t need version pinning
POCs and experimental projects
Anywhere you want “set it and forget it” version management
Want to know which version you’re actually hitting? Check the X-SailPoint-Route-Version response header. It tells you exactly where your call was routed.
Keep in mind
/latest is powerful, but it’s not for everything. Production systems and mission-critical workflows should still use explicit versions (like /v2025/accounts) to avoid surprises when breaking changes land in a new annual release.
Think of /latest as your development accelerator, and explicit versions as your production safety net.
I like how this latest endpoint takes into account that newer endpoint versions that are still experimental are not taken into account yet. Are beta endpoints considered experimental or public here? Asking this for endpoints such as governance groups, where the v2025 endpoint is still experimental, while there is a beta version. Which one will the latest use?
Will there be a https://developer.sailpoint.com/docs/api/latest documentation page, where the documentation inherits the documentation bit from the endpoint that would be used? For example some APIs might already exist in v2026 while others still fall back on v2025 or maybe even earlier.
It is really important that customers and partners are informed that the latest API should not be used in production as breaking changes would definitely occur. If this message is not conveyed properly, SailPoint might be less inclined to make breaking changes on endpoints that should have breaking changes to ensure their updated behavior matches convention (think of fixing launchers pagination such that it uses the same logic as pagination of other object types, or fixing ownership reference such that owner.name always refers to the same identity attribute). It would be counter-productive if SailPoint will refrain from making breaking changes that will improve consistency to other SailPoint endpoints, because this latest API usage would then break if not updated.
API endpoints are one of the most used features of ISC. In my opinion there should be a release notes page dedicated to what has changed in API endpoints each week. I would want to know when new endpoints are released, or when endpoints are updated/extended/fixed in some way. Currently, from what I can see, the documentation is updated silently and in order to find the differences, I have to look at each endpoint documentation (or use a crawler to notify me on changes). Similarly if latest endpoint updates to a newer version, I would like to be updated on this, rather then us calling each endpoint daily with X-SailPoint-Route-Version to see if it changed compare to the day before. The risk acknowledgements say:
The best way to help us monitor for these updates would be dedicated API release notes. Right now the alternative is as SailPoint suggests to look at a lot of different places, meaning there is no central spot to look at:
beta endpoints are considered experimental, when we merged them into one collection v2024 beta endpoints went into the experimental state. With that being said calling /latest/workgroups routes to v2025 or the latest experimental version since no public is available.
We have this work planned in the backlog, I don’t have an exact timeline yet.
I’ve heard a release notes or change log page would be beneficial in the past and its definitely on our radar. We are working towards something like this in the future.
This is interesting, do you see the same in dark mode?
I am using markdown highlighting with the / to make certain text pop out. This is the first time I have seen it rendering like this. If you don’t mind can you shoot me a PM about your setup?
