Multi API v3.63.2

Get users' endpoints now include root usersRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user.

The GET /users and GET /users/{user_id} endpoints have been enhanced to include root usersRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. 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 userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user., in addition to authorised usersAuthorised Users Individuals that have been invited by the root user to manage an identity's instruments and transactions. They are not the legal owners of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorised Users.
• GET /users/{user_id} now accepts root userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. IDs and returns root userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. details instead of returning a 404 error

Background

Previously, these endpoints only returned authorised usersAuthorised Users Individuals that have been invited by the root user to manage an identity's instruments and transactions. They are not the legal owners of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorised Users., requiring a separate call to GET /corporates to retrieve root userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. information. This created unnecessary complexity when building user lists, or user-management screens that displayed all users. Root usersRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. are now included in these GET /users endpoints for consistency and ease of integration.

Important Notes

• Root userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. IDs are only accepted in the GET endpoints mentioned above
• Root userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one 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

EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers.: You can now build unified user lists without special handling for root usersRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user.. ConsumersConsumers Individual persons who can be onboarded as identities on Weavr. Consumer identities represent individual customers and require Know Your Customer (KYC) verification. For consumers, the card owner and card assignee are typically the same person. APIs: No breaking changes, existing integrations will continue to work. Root userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user. is still retrieved via GET / consumers.

API keys now managed as API Clients

The way to access API keys in the embedder portalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each. 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 userRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user.) are now managed as part of a broader API Client construct accessible through the API menu item:

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:

Accessing the Postman collections (all embedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. users on Sandbox) is now done through the ‘Developer Resources’ link:

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).