List all memberships of a user: Migration guide

This guide outlines the changes introduced in the List all memberships of a user v2 endpoint (previously known as getUserRoles in v1). The term membership in the following guide refers to the role of a given learner within a given group.

💡

Key changes

• 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.
• Pagination: The v2 endpoint is paginated and returns 1000 memberships per page.

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/users/:userId_or_email/roles
• API v2: /api/v2/users/{userId}/roles

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 'https://{{host}}/api/v1/users/[email protected]/roles?company={{company}}&apiKey={{apiKey}}'

API v2 input example

Shell

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

Main input differences

Change type	API v1	API v2
Modified Parameter	userId_or_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.

Output changes

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

API v1 output example

JSON

[
  {
    "group": "groupID1",
    "roles": [
      "role1",
      "role2"
    ]
  }
]

API v2 output example

JSON

[
  {
    "groupId": "507f1f77bcf86cd799439011",
    "role": "learner"
  }
]

Main output differences

API v2 introduces pagination for the List all memberships of a user endpoint. Instead of returning all groups in a single response, it now returns a maximum of 1000 memberships per page. To retrieve subsequent pages, you need to follow the URL provided in the Link header of the response.

Change type	API v1	API v2
Modified Output property	roles: list of roles of the given user within the given group.	role : role of the given user within the given group. It means that if a user has multiple roles within a given group, you will get as many membership objects as roles they have in the response.
Modified Output property	group: group unique identifier.	groupId: group unique identifier (property renamed).
Added Header	-	Link: String. URL (between < and >) to fetch the immediate next page of results. Only included if there is another page of results.