Are there any API calls that can be used to change an identity attribute for a particular user? I want to do this for testing, but I’m not finding anything in the API documentation that looks like it fits my needs.
Hi @jared-fox
I found one from V2024 or V2025 , but not in standard collection like V3 and Beta.
1 Like
that is not what that endpoint does. you can’t manually update an identity attribute value for a particular identity directly.
2 Likes
Hey @pattabhi thanks for the response. It’s my understanding that the API call you are referring to changes the attribute itself, not the attribute of a particular user. I believe this is what @sup3rmark is pointing out. Unfortunately I started to read the docs on that API call and figured out it was not going to be of any use.
1 Like
You are correct, we will not be able to update the value of an identity
This updates an existing identity attribute. Making an attribute searchable requires that the system , standard , and multi properties be set to false.
Hey @sup3rmark Thanks for your response. I was worried that was the case but wanted to reach out on here and confirm my suspicions. It would be very helpful for the purpose of testing. We have very limited abilities in our sandbox currently and I’m attempting to test some workflows.
Right now I’m trying to work with my dev team to circumvent the sailpoint API collections and have them change it directly in the API that connects our dev environment to the tenant. I’m hoping that works out for us. If not I think we are going to have to have a bigger conversation about creating a test company in our HR system so we can do more robust testing that has better parity to prod.
what I’ve done in the past is create a separate identity profile tied to a web services source that pulls from an Air table set up to mimic the HR source. that way, we can tweak values at will without needing the HR team to mess with their data.
There are certain source types like JDBC where you can “fake” attribute changes by modifying the query but most direct connection sources you aren’t able to modify attribute values unless they’re modified in the source
For sake of testing it might be worth creating a delimited source in your sandbox with the same attributes and data. With that, you’re able to change attribute values of individual accounts using the PUT/PATCH account endpoints
You can’t update the idenity attribute directly , you have to update the source from which these identity are getting created . for testing purpose i would say use the application similar toi IdentiyNow Admins ( flat file ) and you can modify the identity or create new identity .
Or use a Static Transform to return different value for a specific or list of identities.
1 Like
For testing purposes, you can also use the accounts API to directly change the attributes of any account under any source.
So using this endpoint I mean:
As long as you provide all the attributes, this should work.
1 Like
Thank you, I am going to look into this.
I was not familiar with airtables so I looked into it and we are now considering using it. Thanks for the recommendation.
1 Like
@sauvee this doesn’t actually work for direct connection sources (non- this does work, see comments below!delimited file sources).
the documentation you linked for the create endpoint says:
By providing the account ID of an existing account in the request body, this API will function as a PATCH operation and update the account.
and if you look at the doc for the patch endpoint, it says:
Note: The
attributesfield can only be modified for flat file accounts.
i tested this by sending a create with the following payload:
{
"id": "75e234edf93e41b3b0a1528f357de91a",
"attributes": {
"sourceId": "349564bd9ee44929b0fcea16bd4b0eb1",
"mail": "[email protected]"
}
}
this would, presumably, change the mail attribute on my test AD source for the good Admiral to [email protected], but it did not change from its previous value of [email protected]. i also tried this including the id inside the attributes object, same result: i get a 202 response indicating that the task is created, but the change is not actually made.
It does work for all source types, however you need to understand the following:
- Any change you make will be of course overrridden on the next aggregation of the source
- You need to provide ALL attributes as part of your create operation.
3 Likes
holy smokes, you’re right. i pulled in all the attributes (retrieved from a get call) and this worked (the id account ID param needs to be inside the attributes object, for the record). thanks for the new trick, @sauvee!
So that means it’s just updating the account attributes in ISC and not the source system, right?
Yes, you’re essentially just updating the record that exists in ISC. That’s why the information is overwritten in ISC when you do an aggregation from the source directly. And also the reason why it is not ‘supported’ by SailPoint on any source type except Delimited File.
However, as I said for testing purposes or if you really understand the above ‘limitation’, I have found it very useful indeed.
The reason I always use the ‘Create Account’ end point and not update is because it makes your life when doing the API calls much easier. You don’t have to worry about if the account even exists, you just push an account into the source. If it exists, it will update, if not it will create it.
This is an excellent method for testing on sources you have no control over.
What happens if it’s an authoritative source? Is an identity created?
Yes, that’s exactly what happens. In fact you can treat it completely as though it is coming from the (authoritative) source.
Of course, you need to be careful with not testing happy flow paths and completely relying on this, but indeed for initial development and testing it is a life saver.