PUT /v3/accounts - 400 - Action cannot be performed

[mcheek (Mark Cheek)]

Thanks @harshamin9 ,

We are using a service account to perform this action. Since this particular API requires a PAT tied to a user (as opposed to application credentials), we have to use a service account with an identity. Inevitably, you will find there are situations where service accounts with identities will have accounts in some systems, which will result in this issue coming up.

I feel like I’ve said it many times, but the requirement of user context PATs to perform API actions as opposed to application tokens causes issues in many areas, and it’s something that should be addressed. See a similar post below

PUT /v3/accounts Requires ORG_ADMIN token... is this new?

Yes, one can certainly scope the permissions of API credentials to follow least privilege, but you cannot descope an account’s access when logging in interactively, and I think that’s the crux of our issue here. In my observations, there is a lack of (meaningful) API endpoints in IdN that allow for ApplicationOnlyAuth. There are many use cases we have where a single team or account might need to perform a single operation, but in order to do that, we have to grant their account ORG_ADMIN to per…

I have also mentioned how much of a pain it is to generate and manage PATs for service account identities

Generating a PAT through the API for another Identity

I assumed that was the case… please allow me to provide a bit of feedback on the steps I must go through for this process. Note that we create identities for (AD) Service Accounts because we utilize ServiceNow and the IDN API to request and provision access for these accounts. How I generate PATs for these accounts depends on whether or not I want to bypass SSO. If I am logging in using SSO If we are to log in using SSO for these accounts, we have to set up 2FA for that user in Okta. This …