Add a user's role: Migration guides

This guide outlines the changes introduced in the Add a user's role v2 endpoint (previously known as addUserToGroup in v1).

💡

Key changes

• No more input body: The v2 endpoint does not use an input body anymore, as every input parameters are passed along in the endpoint path.
• Identifier type: The v2 endpoint requires user's unique IDs. It no longer accepts an email address as a direct identifier. Migrating requires extra steps if you previously used email. For more information, see the How to identify users in v2 section below.

Documentation links

Here are the links to the API reference for:

• API v1
• API v2

Endpoint mapping

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

• API v1: /api/v1/groups/:group_id/users/:user_email
• API v2: /api/v2/groups/{groupId}/{role}/{userId}

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:

1. 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.
2. 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

Shell

curl --location -g --request PUT 'https://{{host}}/api/v1/groups/567b608a1a92bb4fb526b31a/users/[email protected]?company={{company}}&apiKey={{apiKey}}' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'role=learner'

API v2 input example

Shell

curl --request POST \
     --url https://app.staging.360learning-dev.com/api/v2/groups/507f1f77bcf86cd799439011/learner/507f1f77bcf86cd799439011 \
     --header '360-api-version: v2.0' \
     --header 'accept: application/json'

Main input differences

Change type	API v1	API v2
Modified 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 (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.
Modified Body parameter	role (Body parameter, Required): Role of the added user within the group.	role (Path parameter, Required): Role of the added user within the group.
Removed Body parameter	group_id (Body parameter, Required): Unique identifier of the group to remove the user from.	groupId (Path parameter, Required): Unique identifier of the group to remove the user from.

Output changes

This section details the specific alterations to the successful output returned between API versions.

API v1 output example

JSON

{
  "status": "invitation_created_and_added"
}

API v2 output example

JSON

// 204 No content

Main output differences

Change of paradigm in the response as a successful addition now returns a 204 No content with no response body, instead of a status in v1.