We were evaluating the use of API Management-generated Client Credentials for enable/disable account actions.
The Enable Account and Disable Account docs list both Personal Access Token and Client Credentials as supported auth methods. However, our testing on tenant ta-partner19947.api.identitynow-demo.com shows only PAT works:
| Client Type | Scope | Token | Enable/Disable |
|---|---|---|---|
| PAT | idn:accounts-state:manage |
 |
202 Accepted |
| API Management | sp:scopes:all |
|
 500 Internal fault |
| API Management | idn:accounts-state:manage |
|
500 Internal fault |
The API call only fails for API Management-generated tokens.
Our Analysis
We believe the root cause is the absence of user context in API Management-generated tokens. Per the SailPoint docs, PAT tokens inherit the generating user’s permissions (source), while API Management tokens operate “outside of the context of a user” and “some API calls will not work” (source). The JWT payload confirms this — user_id and identity_id are not set for non-PAT client credentials (source).
The enable/disable APIs trigger provisioning workflows that likely require a user identity to initiate the action. Since API Management tokens lack identity_id and user_id, the provisioning engine fails internally, resulting in a 500 rather than a 403.
Questions
-
Does the “Client Credentials” auth listed on the enable/disable docs refer only to PAT-based credentials, or should API Management clients also work?
-
Is there a way to make API Management clients work for provisioning operations, or is PAT-based credentials the recommended way to make actions work?