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

**URL:** <https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310>\
**Category:** SHF Discussion and Questions\
**Tags:** accounts, identity-security-cloud, apis\
**Created:** [June 18, 2024, 2:26pm UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310 "2024-06-18T14:26:38Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\
**Post date:** [June 18, 2024, 2:26pm UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310/1 "2024-06-18T14:26:38Z")

</div>

We have an RPA process that updates a CSV source using the [create-account](https://developer.sailpoint.com/docs/api/v3/create-account) and [put-account](https://developer.sailpoint.com/docs/api/v3/put-account) API endpoints. The user making an enhancement process is having an issue when calling the PUT endpoint, _specifically when the identity PAT being used is the same identity that the account is linked to_

Notable that I can do it with my own PAT and the identity being used for this process is able to update other accounts, just not its “own”

We’ve not seen this before… is there some documentation saying this isn’t possible?

PUT /v3/accounts/ec67feeb4dc84a6c8683f277d7cdd2cf

```JSON
{
    "attributes": {
        "sourceId": "6e0341d6d14945c09d62efdb3153465e",
        "e-mail": "BOT_ACCOUNT@email.com",
        "groups": [],
        "IIQDisabled": false
    }
}

```

Response

```JSON
{
    "detailCode": "400.1 Bad request content",
    "trackingId": "ad054f878dc64755aa8920a83246f97e",
    "messages": [
        {
            "locale": "en-US",
            "localeOrigin": "DEFAULT",
            "text": "Action cannot be performed on ec67feeb4dc84a6c8683f277d7cdd2cf."
        },
        {
            "locale": "und",
            "localeOrigin": "REQUEST",
            "text": "Action cannot be performed on ec67feeb4dc84a6c8683f277d7cdd2cf."
        }
    ],
    "causes": []
}

```

---

<div class="post-metadata">

**Author:** ![agutschow](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/agutschow/32/8543_2.png) [@agutschow](https://developer.sailpoint.com/discuss/u/agutschow)\
**Post date:** [June 20, 2024, 9:15pm UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310/2 "2024-06-20T21:15:38Z")

</div>

I can’t find any documentation but I recently noticed that I can not access any drop downs or dot menus on my user account from the interface. Maybe this has always been the case but I wonder if what you are seeing is just this the same behavior being applied to a PAT.

Is it possible to create a “service account” to create the PAT token instead of the user using their own?

Alicia

---

<div class="post-metadata">

**Author:** ![VasanthRam](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/vasanthram/32/11764_2.png) [@VasanthRam](https://developer.sailpoint.com/discuss/u/VasanthRam)\
**Post date:** [June 21, 2024, 2:17am UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310/3 "2024-06-21T02:17:22Z")

</div>

Hi @mcheek  
Did you verify the scope of the PAT?  
I think the PAT may not be authorized to the endpoint…  
Thanks, Vasanth

---

<div class="post-metadata">

**Author:** ![harshamin9](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/harshamin9/32/8977_2.png) [@harshamin9](https://developer.sailpoint.com/discuss/u/harshamin9)\
**Post date:** [June 21, 2024, 8:46am UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310/4 "2024-06-21T08:46:44Z")

</div>

Hello @mcheek  
As @agutschow mentioned, we cannot perform any operations related to our own Identity which also includes any updation to the accounts like removing or anything. While ensuring this SailPoint has blocked all modification to existing account for its own Identity even via API’s.  
And anyway for WF’s/Development purposes its always advised to have a service account to generate PAT’s so that even if a employee leaves it does not hamper any operations as Service Account will not be disabled by your teams.

---

<div class="post-metadata">

**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\
**Post date:** [June 27, 2024, 12:48pm UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310/5 "2024-06-27T12:48:41Z")

</div>

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?](https://developer.sailpoint.com/discuss/t/put-v3-accounts-requires-org-admin-token-is-this-new/21834/6):
>
> 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](https://developer.sailpoint.com/discuss/t/generating-a-pat-through-the-api-for-another-identity/14163/12):
>
> 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 …

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [August 26, 2024, 12:48pm UTC](https://developer.sailpoint.com/discuss/t/put-v3-accounts-400-action-cannot-be-performed/67310/6 "2024-08-26T12:48:52Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.