If you saw our earlier heads-up in API Versioning Strategy Updates, this post a follow-up. The website, SDKs, docs, postman collections, and cli have all been updated to use the new versioning strategy.
This is one of the most requested improvements to our developer experience, and it fundamentally changes how our APIs are versioned, documented, and maintained over time — for the better.
Path mapping table reference
This table contains each API and what yearly versions map to the version just released under the new strategy. You’ll see many yearly versions map to a single v1 resource, this is the benefit of the new strategy. Once you migrate to /v1 you won’t have to change it again until the API is deprecated.
Migrating your code with the SDK migration scripts
If you use one of our SDKs, you don’t have to rewrite your integration by hand. We’ve published a migration script for each of the four SDKs (TypeScript, Go, Python, and PowerShell) that automates the bulk of the changes — updating package versions, collapsing the old version namespaces, and adding the new per-method/per-cmdlet version suffixes. Each script walks your project, rewrites your SDK usage in place, and prints a “Manual review required” summary for the handful of cases that need a human eye.
Full step-by-step instructions for every SDK — what each script changes, how to run it, and the manual-review notes — are in the docs:
Before you start: commit or back up your code first (these scripts modify files in place), and run against a clean working tree so you can easily review the diff.
Recommended migration path
Take stock. Identify which ISC APIs and SDK versions your integrations use today.
Check the mapping tables to see where each endpoint now lives under the new per-service versioning.
Run the appropriate SDK migration script — see the SDK Migration Scripts guide — against a clean, committed working tree.
Review the diff and work through the script’s “Manual review required” summary.
Build / type-check / test your integration.
Roll out on your own schedule — you have until Q1 2029 before legacy versions reach end of life, but the sooner you move, the sooner you benefit from the simpler, more stable model.
Questions?
Drop a reply below or start a new topic — we’re happy to help you plan your migration. We’ll also keep this thread updated with links to the mapping tables and any additional migration resources as they’re published.
Hi Philip, Thanks for sharing this info. Previously I used v2026 for roles api (which is not working today-500 Error), when I try with v1 I get 500 error and with same credentials I can get public identities v1.
Hi @philip-ellis , Similarly I have created an utility , which you can add it in the migration steps.
The Workflow Analyzer Utility is an executable tool designed to analyze all SailPoint workflows within a tenant and identify deprecated API usage.
What the Utility Does
The utility:
Connects securely to the SailPoint tenant.
Reads all available workflows.
Inspects workflow HTTP actions.
Identifies API calls made to deprecated API collections.
Generates a detailed report.
Provides recommendations for equivalent ISC APIs where applicable.
The Workflow Analyzer Utility is a read-only assessment tool that scans SailPoint SaaS Workflows, detects usage of deprecated SailPoint API versions (V2026, V2025, V2024, V3, and Beta APIs), and generates a report with recommended ISC API replacements. It requires only the sp:workflow:read permission and helps organizations accelerate migration to SailPoint’s latest supported ISC APIs.
Next to each endpoint there is a link icon, you can click it and copy the link and it looks like this: SailPoint ISC API (V2026) For your question on workflows not showing pagination options, I looked at both of them and the documentation looks the same as it should be, but if you can clarify or show a screenshot of what you think is missing I can look into it more.
This is likely an issue with the API itself and could be scopes related. If you think there is an error on the API then please submit a support ticket for it. If you want to create a new post for help with more details then that is also an option.
Thank you for the link trick @philip-ellis! Here more information regarding the lacking documentation:
Listing workflow executions almost looks good. It correctly shows pagination options as query parameters. But it does not mention count even though using it will populate X-Total-Count (with the wrong value, for example when using limit=2, but still).
Listing workflows is not looking good. It does not show the pagination options as query parameters. It does not mention offset, limit, count, even though they have an effect (and count is working fine as far as I can see).
