Troubleshooting SailPoint Beta API in Workflows: Why System API Keys Fail but Work in Postman

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

We’ve come across an interesting issue when calling SailPoint Beta/v2024 APIs from workflows. While the same API works perfectly in Postman using a system-generated API key, it fails when executed inside a SailPoint workflow. However, when using a user-specific API key (PAT) in the workflow, it works fine.

What’s Happening?

It seems like system-generated API keys don’t always have the necessary context when running inside a workflow execution environment. Some APIs may require a user-bound authentication context to function correctly. Workflows might be running in a restricted system scope, whereas direct API calls (via Postman) don’t have this limitation.

Key Questions for Discussion:

1 Has anyone else faced this issue?
2 Are their specific APIs that enforce user-bound authentication even when system keys are used?
3 Does SailPoint explicitly document when an API requires user authentication in workflows?
4 Are there any workarounds besides using a user-specific PAT?

Let’s discuss! If you’ve encountered this or found a reliable solution, share your insights. :rocket:

2

When we first set up our prod instance we also encounter this issue. And the reason for this is that permissions that the API key has is different from what a PAT can have. Main reason for this is that Non PAT are designed for external systems such as the VA’s. So non PAT have stricter rules applied for security. A PAT is tied to an individual and can be used. Using the IDN Admins source I would create service accounts. Then use these service accounts to generate PAT and use them.