Pseudonymize user: Migration guide

This guide outlines the changes introduced in the Pseudonymize user v2 endpoint (previously known as pseudonymizeUser in v1).

Documentation links

Here are the links to the API reference for:

Endpoint mapping

Here's the direct correlation between the v1 and v2 endpoint URLs:

API v1: /api/v1/users/:user_email/pseudonymize
API v2: /api/v2/users/{userId}/pseudonymize

Behavior changes

How to identify users in v2

A key update in v2 is the standardized method for identifying users. For improved security and consistency, you must now use the user's unique internal ID when referencing a user.

If you already have the internal ID, you can use it directly.
If you only have the user's email address, you'll need to fetch their internal ID first.

To get the user ID based on their email address:

Retrieve and cache all users:
Call List all users to retrieve the full list of users in your organization. To ensure your application is performant, this data should be stored in a local database or cache that is updated periodically.
Find the user and get their ID:
Find the user object where the mail field matches the email you are searching for.
Copy the value of their _id. This is the internal ID.

Input changes

This section details the specific alterations to the input requirements between API versions.

API v1 input example

curl --location -g --request PUT 'https://{{host}}/api/v1/users/:user_email/pseudonymize?company={{company}}&apiKey={{apiKey}}'

API v2 input example

curl --request PUT \
     --url https://app.staging.360learning-dev.com/api/v2/users/userId/pseudonymize \
     --header '360-api-version: v2.0' \
     --header 'accept: application/json'

Main input differences

Change type	API v1	API v2
Modified Path parameter	`user_email` (Path parameter, Required): Could be the email or the ID of the user. This parameter email was part of the URL path.	`userId` (Path parameter, Required): user's internal ID. An email is no longer accepted here. See Behavior changes (section above) for how to get the ID from an email.

Output changes

The output has completely changed to follow RESTful principles. Instead of returning an acknowledgment of the user pseudonymized, we now return the pseudonymized user object.

API v1 output example

{
  "message": "user_personal_data_removed_successfully"
}

API v2 output example

{
  "_id": "507f1f77bcf86cd799439011",
  "mail": "[email protected]",
  "username": "johnsmith",
  "status": "active",
  "lang": "bg",
  "firstName": "John",
  "lastName": "Smith",
  "job": "Engineer",
  "organization": "360Learning",
  "phone": "+33123456789",
  "custom": "Half-time worker",
  "deletedAt": [
    "2025-12-23T10:42:50.300Z"
  ],
  "reactivatedAt": [
    "2025-12-23T10:42:50.300Z"
  ],
  "lastLoginDate": "2025-12-23T10:42:50.300Z",
  "toBeDeactivatedAt": "2025-12-23T10:42:50.300Z"
}

Main output differences

As shown in the example above, the response is completely different, so please refer to the Retrieve a user: Migration guide for more information.

Change type	API v1	API v2
Added Error code		`400 - userNotDeleted`: The given userId does not correspond to a deleted user.
Added Error code		`404 - userNotFound`: The given userId does not correspond to any existing user.