Skip to main content

Version 3.63.2

· 3 min read

Get users' endpoints now include root users​

The GET /users and GET /users/{user_id} endpoints have been enhanced to include root users in their responses, providing you with a unified view of all users within a corporate identity.

What's changed​

  • GET /users now returns all users including the root user, in addition to authorised users
  • GET /users/{user_id} now accepts root user IDs and returns root user details instead of returning a 404 error

Background​

Previously, these endpoints only returned authorised users, requiring a separate call to GET /corporates to retrieve root user information. This created unnecessary complexity when building user lists, or user-management screens that displayed all users. Root users are now included in these GET /users endpoints for consistency and ease of integration.

Important Notes​

  • Root user IDs are only accepted in the GET endpoints mentioned above
  • Root user IDs are not accepted in other user management endpoints such as PATCH /users or POST /users/{user_id}/activate
  • This change maintains backward compatibility with existing integrations

Impact​

Embedders: You can now build unified user lists without special handling for root users. Consumers APIs: No breaking changes, existing integrations will continue to work. Root user is still retrieved via GET / consumers.

API keys now managed as API Clients​

The way to access API keys in the embedder portal is changing. All current API keys that you have in-use remain valid, but are displayed and managed in a new way.

What's changed​

The API keys (accessible only to the root user) are now managed as part of a broader API Client construct accessible through the API menu item:

WEB WEB

Your current API key(s) have been organised under an API Client with Authentication type “User”. You can continue view and manage your keys via the portal as below:

WEB

Accessing the Postman collections (all embedder users on Sandbox) is now done through the ‘Developer Resources’ link:

WEB

Background​

The changes are being done to support an ongoing initiative to support additional API authentication mechanisms (such as using a certificate instead of a user auth_token).