Taurus-PROTECT has a robust change approval system where each change must be approved by admins or in some cases, superadmins. This endpoint can be used to make change requests to users, wallets, whitelisted addresses, and more.
This endpoint creates a new change which is then sent to admins or in some cases superadmins for approval. It is the same endpoint that powers the PROTECT web and desktop applications.
Entities represent what is being changed. For example, a user, a group, a wallet, etc. The action represents what is being done to the entity. For example, creating a new user, updating an existing user, deleting a user, etc. Each entity can accept different fields which are passed to the API as JSON in the changes parameter.
The following table lists the supported entities, actions and valid change fields.
Entity Actions & Valid Change Fields
Entity | Supported Actions | Valid Change Fields |
|---|---|---|
User | create, update, delete, resetpassword, resettotp, resetkeycontainer | firstname, lastname, status, roles, externaluserid, username, publickey, email, userid, keycontainer |
Group | create, update, delete | name, externalgroupid, description, groupemail |
UserGroup | create, update, delete | name, externalgroupid, description |
Exchange | create, update, delete | name, symbol, country, website |
BusinessRule | create, update, delete | rulekey, rulevalue, rulewalletid |
Rule | create, update, delete | name, description, condition, action |
Price | create, update, delete | blockchain, currencyfrom, currencyto, decimals, rate, source, currencyfromid, currencytoid |
TPAction | create, update, delete | label, autoApprove, trigger, tasks, state |
FeePayer | create, update, delete | name, network, blockchain, address |
SecurityDomain | create, update, delete | name, description, mode, openid_configuration_url |
UserApiKey | create, update, delete | key, description, permissions |
VisibilityGroup | create, update, delete | name, description, members |
UserVisibilityGroup | create, update, delete | userid, visibilitygroupid |
Wallet | create, update, delete | address, network, type, balance |
WhitelistedAddress | create, update, delete | address, network, type, description |
ManualAccountFreeze | create, update, delete | account, reason, duration |
ManualUTXOFreeze | create, update, delete | utxo, reason, duration |
Entity specific processing rules
The changes API implements CRUD semantics on various entities, where each entity type has its own processing rules. Here are some of the entity-specific rules that apply. Note that this list is non-exhaustive.
All Entities
- You cannot create a change which already exists. The API will return an error.
- Once a change has been created, it cannot be edited. You must reject the change and create a new one.
- Once approved, changes are applied immediately by PROTECT.
User
User- Super admin users cannot be deleted.
- A user's
Super Adminrole cannot be removed. - Only
firstname,lastname,email,username,statusandrolescan be changed for Super Admin users. - All users must have an
externalUserID(typically an email address).
Groups
Groups- If SSO is enabled, groups changed via SCIM cannot be changed manually.
- Groups are automatically reset for SSO users on the next login, creating a change request.
Account Freezes
- There are two different endpoints for account freezes depending on if a blockchain is account based (e.g., Ethereum) or utxo based (e.g., Bitcoin).
- Freezing an amount (account based blockchain)
- Freezing an amount (utxo based blockchain)