Update Policy

Update an existing policy.

Authentication

✅ Organization User (CustomerEmployee)
❌ Delegated User (EndUser)
✅ Service Account

Required Permissions

Policies:Update: Always required.

Authorizations

Authorization · string · header · required

Bearer Token: Used to authenticate API requests. More details how to generate the token: Authentication flows

X-DFNS-USERACTION · string · header · required

User Action Signature: Used to sign the change-inducing API requests. More details how to generate the token: User Action Signing flows

Path Parameters

policyId · string · required

Minimum length: 1

Body

application/json

Registry:Addresses:Modify

name · string · required

activityKind · enum<string> · required

Available options:

Registry:Addresses:Modify

rule · object · required

This rule will always be triggered, meaning that if this rule is defined on a policy, the policy will always trigger the policy action, regardless of the activity details.

Show child attributes

action · object · required

This action means that activity will first require an Approval process to be completed before it can be executed (or be aborted if someone rejects it during the approval process).

One or several groups of approvers need to be specified. These groups define who is allowed to approve / reject an activity.

The activity will only be executed if all approver groups reach their "quorum" of approvals. Otherwise, if any one user within any approver group rejects, then the activity is aborted and the call is not executed.

The example below shows a RequestApproval action, configured with one approval group requiring 2 approvals amongst three specific users.

{
  "action": {
    "kind": "RequestApproval",
    "autoRejectTimeout": 60, // minutes
    "approvalGroups": [
      {
        "name": "Admins",
        "quorum": 2, // only 2 approvers required in that group 
        "approvers": {
          "userId": {
            "in": ["us-...1", "us-...2", "us-...3"],
          }
        }
      }
    ],

  }
}

Don't lock yourself up

By default, users cannot approve an activity they initiated themselves, even if they are in an approval group. To allow this, you must set initiatorCanApprove: true.

Example 1: For any wallet transfer, a policy is setup to require approval from 1 specific admin user (eg. the CEO). initiatorCanApprove was not set to true. If the CEO himself initiates a transfer, no-one can approve his transfer and it's stuck.

Example 2: Company has only 3 users. A policy is setup to require approval from any 3 users (quorum: 3) for any modification of a policy. initiatorCanApprove was not set to true. In this case, they are locked, and the policy cannot be modified: whoever requests a modification cannot approve, and the policy is therefore always missing one approver. To unlock, they would need to invite a new user and give him the rights to approve as well.

RequestApproval

Show child attributes

filters · object

Response

200 - application/json

Success

Registry:Addresses:Modify

id · string · required

name · string · required

status · enum<string> · required

Available options:

Active,

Archived

activityKind · enum<string> · required

Available options:

Registry:Addresses:Modify

rule · object · required

This rule will always be triggered, meaning that if this rule is defined on a policy, the policy will always trigger the policy action, regardless of the activity details.

Show child attributes

action · object · required

This action means that activity will first require an Approval process to be completed before it can be executed (or be aborted if someone rejects it during the approval process).

One or several groups of approvers need to be specified. These groups define who is allowed to approve / reject an activity.

The activity will only be executed if all approver groups reach their "quorum" of approvals. Otherwise, if any one user within any approver group rejects, then the activity is aborted and the call is not executed.

The example below shows a RequestApproval action, configured with one approval group requiring 2 approvals amongst three specific users.

{
  "action": {
    "kind": "RequestApproval",
    "autoRejectTimeout": 60, // minutes
    "approvalGroups": [
      {
        "name": "Admins",
        "quorum": 2, // only 2 approvers required in that group 
        "approvers": {
          "userId": {
            "in": ["us-...1", "us-...2", "us-...3"],
          }
        }
      }
    ],

  }
}

Don't lock yourself up

By default, users cannot approve an activity they initiated themselves, even if they are in an approval group. To allow this, you must set initiatorCanApprove: true.

Example 1: For any wallet transfer, a policy is setup to require approval from 1 specific admin user (eg. the CEO). initiatorCanApprove was not set to true. If the CEO himself initiates a transfer, no-one can approve his transfer and it's stuck.

Example 2: Company has only 3 users. A policy is setup to require approval from any 3 users (quorum: 3) for any modification of a policy. initiatorCanApprove was not set to true. In this case, they are locked, and the policy cannot be modified: whoever requests a modification cannot approve, and the policy is therefore always missing one approver. To unlock, they would need to invite a new user and give him the rights to approve as well.

RequestApproval

Show child attributes

dateCreated · string

dateUpdated · string

filters · object