Skip to main content
  • For adding users via the console please refer to this guide
  • For adding users via the API please refer to the following API endpoints. Generally, there are different user roles that can be assigned to a specific user, please see the user role table below:
There are different API Key types. Each type contains other capabilities in addition to transaction permissions.
Initiating vs. signing transactions. “Can’t sign transactions” refers only to the signing step. Non-Signing Admin and Editor can still initiate transactions through the Fireblocks Console or API, for example, by calling POST /transactions. Approver cannot initiate transactions, only approve them. When Non-Signing Admin or Editor initiates a transaction, a separate signer (Admin, Signer, or NCW_SIGNER) designated by the workspace Transaction Authorization Policy (TAP) signs it. This lets you segregate the initiator, approver, and signer across different API users. See Segregate Duties for common role splits.
Defining users in your workspace may seem straightforward, but it requires careful alignment with the supported roles. Whether your goal is maximum security or optimal work efficiency, the right approach depends on your specific business use cases. Before getting started, familiarize yourself with user groups and approval groups. These two features are crucial for defining user roles and actions in your Fireblocks workspace and can significantly enhance your operational efficiency and security.
  • Segregate users into two categories: those responsible for managerial decisions and changes, and those handling day-to-day operations. Differentiating between users who can make changes in the workspace and those who can only initiate or sign transactions will enhance security. For more details, refer to this guide.
  • Always consider the admin quorum approval. The more approvals required for a workspace change, the longer and more complex the implementation process will be.
  • Start by defining groups and their tasks. Based on these tasks, identify the roles that match and add individual users accordingly. Managing your operations with the correct setup of groups will enhance the performance of regular operations and facilitate general workspace changes.
Follow the general best practices when choosing users and roles as outlined here.

​
API Users Use Cases

API users can be used either to access Fireblocks API or to be paired with a cosigner (one can be both at the same time, but this is not the best practice). In the case of an API user used to access the API, it has API key and API Secret that are required for authentication. In the case of an API user paired with a cosigner, it has MPC key shares if it’s a Signer or Admin, a One-time pairing token, and Device in case it’s an API user that is paired with a device. In the case of an API user used for KeyLink, it does not have MPC keys, but it has the pairing token, the access token, and the device.