Endpoints and payload details

Updated as of 07/1/2025

Overview

The following API endpoints allow wealth platforms to submit onboarding applications for their individual or institution end clients and create subaccounts for use at Anchorage Digital. Joint subaccounts can be created between multiple end clients, and a single end client can have multiple subaccounts.

These endpoints collect data and documentation for Anchorage Digital to satisfy its regulatory obligations to perform Know Your Customer (KYC), Customer Identification Program (CIP), Customer Due Diligence (CDD), and Enhanced Due Diligence (EDD) on its clients and related parties. Once submitted, each end client or subaccount application is screened and approved.




Customer onboarding endpoints

  • POST /v2/onboarding/customers : create a new end client onboarding application (individual or institution)
  • GET /v2/onboarding/customers : return information about all existing onboarding applications associated with this API key
  • GET /v2/onboarding/customers/{{customerId}} : return information about an existing end client onboarding application
  • PUT /v2/onboarding/customers/{{customerId}} : update an existing end client onboarding application
  • POST /v2/onboarding/customers/{{customerId}}/document : retrieve a signed URL for uploading a document image for an existing end client application
  • POST /v2/onboarding/customers/{{customerId}}/submit : submit a completed end client onboarding application
  • POST /v2/onboarding/agreements/terms : create new terms for a signer to sign
  • GET /v2/onboarding/agreements/terms : return information about all existing terms
  • GET /v2/onboarding/agreements/terms/{{termsAgreementId}} : return Docusign signed URL for the terms



Payload data

Each endpoint accepts a data payload with an entries object containing tag/value pairs. The required and optional data for each endpoint is explained in the tables below.

{
  "entries":[
    {
      "key":"boolField",
      "value":true
    },
    {
      "key":"numberField",
      "value":10
    },
    {
      "key":"stringField",
      "value":"stringFieldValue"
    },
    {
      "key":"collectionField",
      "value":[
        "collectionField0Value",
        "collectionField1Value"
      ]
    },
    {
      "key":"objectField",
      "value":{
        "field0":"field0Value",
        "field1":"field1Value",
        "field2":"field2Value"
      }
    },
    {
      "key":"objectCollectionField",
      "value":[
        {
          "field0":"field0AValue",
          "field1":"field1AValue",
          "field2":"field2AValue"
        },
        {
          "field0":"field0BValue",
          "field1":"field1BValue",
          "field2":"field2BValue"
        }
      ]
    }
  ]
}
📖

Notes

  • Some of the data is conditional and described in the payload detail, when applicable.
  • The payload data elements support versioning to not cause breaking changes. An optional parameter applicationVersion is used to specify the version of the application payload. The default value of this is 0 and will point to the latest version of the application. The current latest version is 1 and all new breaking changes in the payload will be applied to a newer version.
  • String field value sizes are limited to 512 characters, but some fields have further restrictions. They are listed in tables below under the Value Restrictions column.

Did this page help you?