Hi @kevter, the PATCH request that you’re making seems correct.

Could you confirm that the user id that you’re using in the request is correct? You can also use the SCIM get users endpoint to get a list of users and their IDs, instead of using the REST API endpoint.

Hi @kevter, adding some additional details here as well.

You’ve noted that you are using getting the user ID via REST API. One possibility for this 404 error is that the Organizations REST API will give "all" users within their Miro Org regardless of their role (it will return Company Admins, Members, Guests and Team-Guests) but SCIM can only see "Members" and "Company Admins".

If the userID is of a "Guest" or "Team-Guest", SCIM will return a 404 error because that userID is not a valid "Member" nor "Company Admin" ID. Since you are using SCIM anyway, you can get the userID using SCIM itself, this way they eliminate the potential error that the userID is not a valid Member/Admin. To get the userID of a user with SCIM using the E-Mail address, they can use the below SCIM API URL:

https://miro.com/api/v1/scim/Users/?attributes=id,userName&filter=(userName eq "user@miro.com")
 

Or if you prefer to escape the value of the URL parameter, it would be something like:

https://miro.com/api/v1/scim/Users/?attributes=id%2CuserName&filter=(userName%20eq%20%22user%40miro.com%22)

In the response you'll get the Miro User ID and can then do the PATCH call to update the userName.

Please let me know if it helps!

Hi @Josip Janzic and @Horea Porutiu - thanks for the replies. I changed the script to get the ID using  SCIM with a filter and that works fine, so it’s not the token. To validate it isn’t something in my script, I tried running the patch in Insomnia, adding the payload data to the Body section, and I get an error there too (the SCIM get does work in Insomnia). Would support be able to lookup the error code to provide more information?

Hi @kevter 

Thanks so much for taking the steps to confirm it wasn’t an issue with the User ID. 

The screenshot you’ve shown is from the browser, so doesn’t really help us identify the problem. 

Could you please show a screenshot from Insomnia or Postman which shows the following:

1. full API URL
2. The call type (in this case PATCH)
3. Full body of the payload
4. The response code and response text. 

Something like below (which worked fine on our side)

 

@Horea Porutiu That image actually was from Insomnia. Here’s the broader image with details.

Hi @kevter 

I think the URL you are using is not correct. Could you please try this instead?

https://miro.com/api/v1/scim/Users/<userID>

The base URL you are using is api.miro.com but for SCIM API it should be just miro.com. Please see the screenshot above (which I posted) to find the correct API URL. 

Let me know if this solves your issue, thanks! 

Oh no! That was it!! Thank you @Horea Porutiu.

Happy to help! All the best, let me know if you have any other questions! 

Hi @Horea Porutiu - I do have another question related to this. We ran into a situation where a user had a name change, but our automation created a new account for her with the new last name. When I tried to run my script, I got a 409 response (conflict), which I presumed was because the name I was trying to change to already existed. I do see in the debug detail that it says user@domain.com is not unique. So I deactivated and deleted the “new” account that had her updated name, but I’m still getting the 409. Does it take a while for what I see in the GUI and the API to sync? Thank you.

Hi @kevter 

Let’s see if we can find the root of this issue.

 

Generally, a new user can only be created via POST call, whereas updates to existing users are done via PATCH call and by providing the exact user ID to update.

Are you using the SCIM API directly only or are you using a mix of SCIM API and SCIM via IdP?

You cannot fully erase a user profile.

Deleting a user (either via SCIM or from the Miro UI) only removes the connection between the user and their Miro org but it does not eliminate the user profile and that's you are seeing a 409 error.

To correct this situation we need to see why the logic is creating duplicates. This is the most important part because this may then happen again with every name/email updates. A PATCH update call will never create a new user. Either something triggered a POST to create the new user or their IdP did it (if they are using SCIM via IdP too).

To fix this particular user in question you will need to:

1. Re-invite the new user, which currently holds the correct Email (with the updated lastname) into their Miro org again. This is to allow them to perform updates on this new user via SCIM again. As long as the new Email is occupied by another user, they won't be able to take it for the correct employee.
2. Trigger a PATCH call on this new user to change the userName to something totally new (e.g. user_duplicate_error@domain.com). This is to make the correct Email available again to be assigned to another user.
3. Trigger a PATCH call on the old/original user to update the userName with new correct Email (with the updated lastname)
4. Deactivate or delete the new user with the user_duplicate_error@domain.com Email
    

Please let me know if this solved it.

Thank you @Horea Porutiu. So if our automation creates a new user account based on that new email address, even if we delete it we won’t be able to change the email address of an existing account to that email?

We are not syncing users via SCIM, instead using SCIM API to automate provisioning based on AD security group membership. Our authentication system does not support sync with SCIM.

Hi @kevter sorry for the late response here, I was on PTO last week. Here is what I heard back from our team:

they need to adjust their logic to identify if the new Email address is due to an Email change or due to the addition of a brand new user. If it's an Email change, they need to call the SCIM PATCH endpoint to update the existing user in Miro. If it's not an Email change but a new user, then they can do the POST call. If they do a POST call and create a new user in Miro with the new Email first, they won't be able to use the new Email for existing user because it's now occupied by the new user, even if they delete it. SCIM deletion alone will not free up the incorrectly created user, because the profile remains existing in Miro. The SCIM delete call simply cuts the connection between the user and their Miro org but the profile remains existing. They can update Email addresses, they just have to adjust the order of execution.

If they already made the mistake to create a new user with the new Email, they can only correct it by following the steps mentioned previously, this is because the SCIM delete call doesn't erase the user profile in the Miro system, it only cuts the connection between the profile and their Miro org. Alternatively they can contact Miro Support, in which case Support will take care of the update manually but they can do it themselves too. 

Please let me know if this helps.

@Horea Porutiu, thanks for the update. Unfortunately the response from the dev team isn’t feasible in our scenario. We want to provision users as quickly as possible, so our automation script runs hourly and goes out to check AD security group memebership. If a new user shows up there, the automation adds the email address. At that point, we are unable to do anything via the API. Except maybe rename that new account to something like firstName.lastName.DELETE@domain.com? Would that work? This seems like an unnecessary step though if you delete the account completely through the GUI. It shouldn’t still be there hiding in the backend via API where it’s in this limbo state.

Hi @kevter 

Neither SCIM nor their Miro Admins have the power to fully erase Miro profiles in entire Miro platform once created, they can only "delete" the connection between the user profile and their Miro account. This is like this by design - if this was possible IT Admins would have the power to delete anyone who ever joined their account - even if that user has content on other Miro orgs, so Miro won't allow this.

They only have power over the relationship between the user and their Miro org, not over the user in the entire Miro platform overall.

Email addresses are unique in Miro (for the entire Platform - not just their account). Once they create a profile with an Email, nobody else in the entire Miro platform can use that Email. Deleting does not solve the profile because deleting won't erase the profile.

This conversation is going out of scope for this developer public forum. You are talking about some pretty specific logic here which seems to be catered to your particular use case. 

I suggest to continue this conversation on a Miro Support ticket or talk to their CSM to engage Professional Services, Onboarding Consultants or Solution Engineers, who can go over this on a call.