​

Added Staking and Delegation Reward Transaction Types for Subaccounts

• Improved: Added new transaction types, STAKING_REWARD and DELEGATION_REWARD, to provide more detailed transaction information for subaccounts involved in staking.
  • Category: Subaccounts
  • Endpoints Changed:
    • GET /subaccounts/transactions
    • GET /subaccounts/transactions/{transactionsIds}
    • GET /subaccounts/transactions/allocations
  • Impact: The transactionType field in the response objects for the listed endpoints will now include STAKING_REWARD and DELEGATION_REWARD enum values. This enables more granular tracking and filtering of staking-related activities.
  • Parameters: The types query parameter for the GET /subaccounts/transactions endpoint now supports filtering by these new transaction types.
  • Example: A response from GET /subaccounts/transactions may now include transactions like the following:
    {
      "data": [
        {
          "transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d",
          "transactionType": "STAKING_REWARD",
          "status": "POSTED",
          "createdAt": "2024-08-01T12:00:00.000Z",
          // ... other fields
        }
      ]
    }
    

​

Added New Rejection Reason for Trading Orders

• Improved: Added the InvalidCurrencyForFOK enum value to the rejectReason field in the responses for several trading endpoints.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/order
    • POST /trading/async-order
    • POST /trading/async-order/cancel
  • Impact: This provides more specific feedback when a FillOrKill (FOK) order is rejected due to an invalid currency, improving error handling.

​

Enhanced Staking Request with Asset-Specific Parameters

• Improved
  • Description: The POST /transactions/stake endpoint has been updated to support specific configuration parameters for different assets when creating a staking request. The parameters field in the request body is now a structured object that allows for more granular control over staking operations.
  • Category: Transactions
  • Endpoint Changed:
    • POST /transactions/stake
  • Request Body:
    • The parameters field now accepts a structured object for asset-specific configurations, such as parameters for SOL and ETH staking.
  • Impact: This change allows you to provide detailed configurations for staking requests on a per-asset basis, enhancing flexibility and control.
  • Additional Information: As noted in the API documentation, the functionality for these specific asset parameters is currently under development.

​

Added Asset-Specific Staking Parameters

• Added
  • Added a new parameters object to the request body for creating stake requests, allowing for asset-specific configurations.
  • Category: Transactions
  • Endpoint Changed: POST /transactions/stake
  • Request Body: The request body now accepts a new parameters object to set specific configurations for staking. This can include:
    • stakingProvider: The validator’s provider (e.g., FIGMENT, BLOCKDAEMON).
    • stakingProviderAddress: The validator’s staking address.
    • stakingPositionId: The identifier for an existing staking position.
    • validatorType: Defines the validator to use for certain assets (e.g., 0x01 for Pre-Pectra, 0x02 for Post-Pectra).
  • Impact: This change provides more granular control over staking operations by allowing users to specify validator details and other asset-specific parameters directly in the request.

​

Added Talos as a Price Source Provider for Collateral Management

• Added TALOS as a supported price source provider for Collateral Management.
  • Type: Added
  • Category: Collateral Management
  • Endpoints Changed:
    • POST /collateral_management/exposures
    • POST /collateral_management/packages
  • Request Body: The priceSourceProvider field within the assetTrackingConfig for exposures and collateralAssetsConfig for packages now accepts TALOS as a valid enum value.
  • Impact: You can now specify TALOS as the provider for consolidating pricing data when creating new collateral exposures and packages.

​

Improved Stablecoin Conversion Descriptions

• Improved
  • Updated the descriptions for the sourceAssetType and destinationAssetType fields to provide clearer guidance on their usage for issuance and redemption operations.
  • Category: Stablecoins
  • Endpoint Changed: POST /stablecoins/conversion
  • Request Body:
    • The description for sourceAssetType was clarified to state that for issuance, the value must be USD, and for redemptions, it must be the asset being redeemed.
    • The description for destinationAssetType was clarified to state that for issuance, the value must be the stablecoin asset, and for redemptions, it must be USD.
  • Impact: This is a non-breaking documentation change to improve clarity. The endpoint’s functionality remains the same.

​

Enhanced Price Source Configuration in Collateral Management

• Improved price source configuration by introducing a priceSourceProvider field.
  • Type: Improved
  • Category: Collateral Management
  • Endpoints Changed:
    • POST /collateral_management/exposures
    • POST /collateral_management/packages
  • Request Body:
    • For POST /collateral_management/packages, the priceSourceProvider field has been added to the objects within the collateralAssetsConfig array. The KAMINO enum value has been removed from the priceSource field.
    • For POST /collateral_management/exposures, the priceSourceProvider field has been added to the assetTrackingConfig object. The KAMINO enum value has been removed from the priceSource field.
  • Impact: This change provides more granular control over pricing data by separating the service provider from the underlying price source. KAMINO is now a priceSourceProvider instead of a priceSource.
  • Additional Information: Users creating collateral packages or exposures now have a new optional priceSourceProvider field to specify the service provider for pricing data. The KAMINO option has been moved from the priceSource field to the priceSourceProvider field.

​

Improved Trading Statuses and Tax Endpoint Responses

• Improved
  • Description: We’ve enhanced the trade lifecycle tracking by adding two new statuses to the tradeStatus enum: PENDINGALLOCATION and ALLOCATED.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/quote/accept
    • GET /trading/trades
    • GET /trading/trades/{tradeId}
    • GET /trading/settlements/{settlementId}/trades
  • Impact: Responses from these endpoints may now include these new statuses, providing clearer insight into the allocation phase of a trade.
    • PENDINGALLOCATION: The trade is executed and is awaiting client allocation.
    • ALLOCATED: The trade is fully allocated by the client.
• Improved
  • Description: The response for asynchronous tax tagging operations has been updated to provide a more accurate status.
  • Category: Tax
  • Endpoints Changed:
    • POST /tax/transaction/{transactionId}/tag
    • DELETE /tax/transaction/{transactionId}/tag
  • Impact: These endpoints now return a 202 Accepted status code to indicate that the request has been successfully received and is being processed, rather than implying immediate completion.

​

Added KAMINO as a Price Source for Collateral Management

• Improved
  • Description: Added KAMINO as a new enum value for the priceSource field when creating collateral packages and exposures.
  • Category: Collateral Management
  • Endpoints Changed:
    • POST /collateral_management/packages
    • POST /collateral_management/exposures
  • Request Body: The priceSource field within the collateralAssetsConfig (for packages) and assetTrackingConfig (for exposures) objects now accepts KAMINO as a valid enum value.
  • Impact: Users can now specify KAMINO as the source for price information when creating new collateral packages and exposures.

​

Added Optional Price Staleness Configuration for Collateral Packages

• Added an optional maxStalenessMinutes field to the request body for creating collateral packages. This allows for configuring the maximum age of an asset’s price before it is considered stale.
  • Category: Collateral Management
  • Endpoint Changed: POST /collateral_management/packages
  • Request Body: A new optional integer field, maxStalenessMinutes, can now be included in each object within the collateralAssetsConfig array.
  • Impact: This is a non-breaking change. If the maxStalenessMinutes field is not provided, the system will use a default value of 3 minutes.
  • Example:
    {
      "pledgorId": "...",
      "securedPartyId": "...",
      "collateralAssetsConfig": [
        {
          "asset": {
            "type": "ANCHORAGECUSTODY",
            "assetType": "BTC"
          },
          "weight": "0.85",
          "liquidationPriority": 1,
          "maxStalenessMinutes": 5
        }
      ],
      "priceStrategy": "DEFAULT"
    }
    

​

Enhanced Vesting Balances Response

• Improved
  • The response for getting vesting balances now includes externalTokenId and networkId for added asset context.
  • Category: Vesting
  • Endpoint Changed: GET /vesting/balances/{allocationId}
  • Impact: The balance object in the 200 OK response now contains two new required fields: externalTokenId and networkId. This is a non-breaking additive change.
  • Additional Information:
    • externalTokenId: The ID of the asset assigned by the external provider.
    • networkId: The identifier for the blockchain network.

​

New Tax Endpoints and Trading Status Updates

• Added endpoints for managing tax transaction tags.
  • Category: Tax
  • Description: Introduced two new endpoints to programmatically add and remove tags from transactions. This feature enhances transaction management for tax purposes.
  • Endpoints Added:
    • POST /tax/transaction/{transactionId}/tag
    • DELETE /tax/transaction/{transactionId}/tag
  • Impact: Users can now organize transactions with tags for easier tracking and reporting.
• Improved status field descriptions for Trading endpoints.
  • Category: Trading
  • Description: The descriptions for the quoteStatus and tradeStatus fields have been updated for greater clarity. The tradeStatus field has been expanded to include PENDINGALLOCATION and ALLOCATED to provide more granular status tracking.
  • Endpoints Changed:
    • POST /trading/quote
    • POST /trading/quote/accept
    • GET /trading/trades
    • GET /trading/trades/{tradeId}
    • GET /trading/settlements/{settlementId}/trades
  • Impact: These changes provide more detailed information about the state of quotes and trades. The addition of PENDINGALLOCATION and ALLOCATED statuses offers better visibility into the post-execution process.

​

Added stakeholderId Parameter to Vesting Balances Endpoint

• Added an optional stakeholderId query parameter to the GET /vesting/balances/{allocationId} endpoint.
  • Category: Vesting
  • Endpoint Changed: Get vesting balances for an allocation
  • Method: GET
  • Path: /vesting/balances/{allocationId}
  • Parameters: The new optional stakeholderId query parameter can be used to retrieve wallet information for a stakeholder, which is particularly useful when no transactions exist yet.
  • Impact: This is a non-breaking change that improves the ability to retrieve wallet information for newly created stakeholders before any transactions have occurred.

​

Added FIAT_BANKING Permission

• Improved: Added the FIAT_BANKING permission type.
  • Category: API Key
  • Endpoint Changed: GET /apikey
  • Description: The response for the GET /apikey endpoint may now include FIAT_BANKING as a value in the permission field within the permissions array.
  • Impact: API clients that parse the permissions array should be updated to handle the new FIAT_BANKING enum value.
  • Example:
    {
      "data": {
        "id": "b5a58566763e77e2d87a53463013981be7c0b048c1c0dd39ba44e77c99bc1351",
        "permissions": [
          {
            "permission": "READ",
            "vaultIds": [
              "1c920f4241b78a1d483a29f3c24b6c4c"
            ]
          },
          {
            "permission": "FIAT_BANKING"
          }
        ]
      }
    }
    

​

Improved Parameter Descriptions for Delegation Addresses

• Improved: Updated the descriptions for parameters on the GET /delegation-addresses/{assetType} endpoint to provide better clarity.
  • Category: Transactions
  • Endpoint Changed: List supported delegation addresses
  • Method: GET
  • Path: /delegation-addresses/{assetType}
  • Parameters: The descriptions for the assetType, afterId, and limit parameters have been improved.
  • Impact: This is a non-breaking documentation change with no impact on API functionality.

​

Added New Endpoint for Listing Delegation Addresses

• Added a new endpoint to list supported delegation addresses for staking.
  • Category: Transactions
  • Endpoint Changed: GET /delegation-addresses/{assetType}
  • Description: This new endpoint allows you to retrieve a list of supported delegation addresses for a specific asset type. This is useful for identifying valid addresses before initiating staking operations.
  • Impact: Users can now programmatically discover available delegation addresses for a given asset.
  • Additional Information: This endpoint requires the Initiate Staking and Unstaking permission.

​

Enhanced Delegation Address Information

• Improved: The response for GET /delegation-addresses/{assetType} now includes additional details about the validator for each delegation address.
  • Category: Delegation Addresses
  • Endpoints Changed: GET /delegation-addresses/{assetType}
  • Impact: The data array in the response for listing delegation addresses will now contain two new required fields for each address object: anchorageValidator (boolean) and validatorType (string).
  • Additional Information: These fields allow you to determine if a delegation address belongs to an Anchorage Digital validator and to identify the type of validator.
  • Example:
    {
      "data": [
        {
          "address": "...",
          "name": "Validator Name",
          "anchorageValidator": true,
          "validatorType": "ENTERPRISE"
        }
      ]
    }
    

​

Made Amount Optional for Staking Collect Requests

• Improved
  • The amount field in the request body for POST /transactions/collect is now optional.
  • Category: Transactions
  • Endpoint Changed: POST /transactions/collect
  • Request Body: The amount property is no longer required.
  • Impact: This change provides more flexibility. You can now omit the amount field when intending to collect the full inactive unstaked amount for a given staking position.
  • Additional Information: If the amount is not specified, the request will default to collecting the entire available amount.

​

Added Endpoint to List Delegation Addresses

• Added a new endpoint to list supported delegation addresses for a given asset type.
  • Category: Addresses
  • Endpoint: GET /delegation-addresses/{assetType}
  • Impact: This allows users to programmatically discover valid delegation addresses for specific assets, which can be used to automate staking and delegation operations.
  • Example:
    curl --request GET \
      --url 'https://api.anchorage.com/v2/delegation-addresses/ETH' \
      --header 'Api-Access-Key: <YOUR_API_KEY>'
    
  • Additional Information: This endpoint helps streamline staking workflows by providing a reliable way to fetch supported delegation targets directly via the API.

​

Added Endpoint to Update Customer Onboarding Applications

• Added the ability to update existing customer onboarding applications
  • Description: A new PUT endpoint has been introduced to update the data of an existing customer onboarding application. This allows for modifications to be made to an application before it is submitted for review.
  • Category: Onboarding
  • Endpoints Changed:
    • PUT /onboarding/customers/{customerId}
  • Methods: PUT
  • Paths: /onboarding/customers/{customerId}
  • Request Body: The endpoint accepts an entries array containing the key-value pairs of the application data to be updated.
  • Impact: Users can now programmatically correct or add information to a customer’s onboarding application after initial creation but before final submission.
  • Example:
    PUT /onboarding/customers/{customerId}
    Content-Type: application/json
    
    {
      "entries": [
        {
          "key": "contactEmail",
          "value": "new.email@example.com"
        }
      ]
    }
    

​

Made Weight Field Optional for Creating Collateral Exposures

• Improved: The weight field within the assetTrackingConfig object is now optional when creating a new collateral exposure.
  • Category: Collateral Management
  • Endpoint Changed: POST /collateral_management/exposures
  • Request Body: The weight field in the assetTrackingConfig object is no longer required.
  • Impact: This change provides greater flexibility by allowing the creation of a collateral exposure without specifying an asset weight.

​

Enhanced Trading Statuses and Staking Operations

• Improved: Added new statuses to the tradeStatus field and updated quoteStatus to provide more detailed information on the trade lifecycle.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/quote
    • POST /trading/quote/accept
    • GET /trading/trades
    • GET /trading/trades/{tradeId}
    • GET /trading/settlements/{settlementId}/trades
  • Impact:
    • The tradeStatus field in responses now includes PENDINGALLOCATION and ALLOCATED, allowing clients to track when a trade is awaiting allocation versus when it is fully allocated.
    • The quoteStatus enum has been updated to consistently reflect the quote lifecycle (OPEN, REJECTED, EXECUTED).
  • Additional Information: These changes provide clearer insight into the state of trades and quotes throughout their lifecycle.
• Improved: Enhanced unstake and collect operations with a full amount option.
  • Category: Transactions
  • Endpoints Changed:
    • POST /transactions/unstake
    • POST /transactions/collect
  • Request Body:
    • For POST /transactions/unstake, the description for the isFullAmount parameter has been clarified to indicate it overrides any provided amount.
    • For POST /transactions/collect, a new isFullAmount boolean parameter has been added.
  • Impact: You can now set isFullAmount: true in the request body for both unstake and collect operations to process the full available balance, simplifying the process by removing the need to first query for the exact amount.

​

Enhanced Staking and Trading Data

• Improved
  • Description: Added the inactiveStakedAmount field to the response for staking positions. This field provides the numeric value of the inactive staked amount, excluding units.
  • Category: Wallets
  • Endpoint Changed: GET /wallets/{walletId}/staking/positions
  • Impact: Users can now retrieve the inactive staked amount for a given staking position, providing more detailed insights into their staking activities.
• Improved
  • Description: The descriptions for the quoteStatus and tradeStatus fields have been updated to provide more clarity on each status. The tradeStatus description now includes details for the PENDINGALLOCATION and ALLOCATED states.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/quote
    • POST /trading/quote/accept
    • GET /trading/trades
    • GET /trading/trades/{tradeId}
    • GET /trading/settlements/{settlementId}/trades
  • Impact: This is a non-breaking documentation enhancement that provides clearer, more detailed explanations for the different statuses of quotes and trades, helping users better understand the lifecycle of their trading activities.

​

Enhanced Tax Form Details

• Improved: Enhanced tax form responses with additional details
  • Category: Tax
  • Endpoints Changed:
    • GET /tax/subaccounts/{subaccountId}/forms
    • GET /tax/clients/{customerId}/forms
  • Details: The response for both endpoints has been updated to include more detailed information for each tax form. The forms object within the response now contains the following new fields:
    • id (string): The unique identifier of the tax form.
    • createdDate (string): The ISO-8601 date-time when the tax form was created.
    • year (integer): The tax year for which the form was generated.
    • revision (integer): The revision number of the tax form.
    • revisionType (string): The type of revision for the tax form.
    • isFiled (boolean): Indicates whether the tax form has been filed.
  • Impact: This is a non-breaking change that provides richer data for tax form management and tracking.
  • Example:
    {
      "data": [
        {
          "subaccountId": "your-subaccount-id",
          "forms": [
            {
              "formType": "1099B",
              "downloadLink": "https://api.anchorage.com/download/link",
              "id": "d290f1ee-6c54-4b01-90e6-d701748f0851",
              "createdDate": "2023-02-10T08:30:00Z",
              "year": 2022,
              "revision": 1,
              "revisionType": "Original",
              "isFiled": true
            }
          ]
        }
      ]
    }
    

​

Improved Descriptions for Creating Trusted Destinations

• Improved: The descriptions for fields in the POST /trusted_destinations request body have been updated to provide better clarity.
  • Category: Trusted Destinations
  • Endpoint Changed: POST /trusted_destinations
  • Request Body: Descriptions for the trustedDestinations array and the name property within the array items have been updated to be more descriptive.
  • Impact: This is a non-breaking documentation change to improve developer experience. No functional changes have been made.

​

Improved Collect Staking Rewards Endpoint

• Improved the request body for creating a collect request to include source, description, and idempotency key.
  • Category: Transactions
  • Endpoint Changed: POST /transactions/collect
  • Request Body:
    • Added the required source object to specify the wallet from which rewards are being collected.
    • Added the optional description string to provide more context for the transaction.
    • Added the optional idempotentId string to support idempotent requests.
  • Response: The 201 Created response now returns a application/json payload upon successful initiation.
  • Impact: This is a breaking change as the source field is now required in the request body. Clients using this endpoint must update their integration to include the source object. The changes make the endpoint more robust and align it with other transactional endpoints.

​

Improved Error Handling for Asynchronous Orders

• Improved: Added a new reject reason, InvalidAccountsInAllocation, to provide more specific feedback when an asynchronous order fails due to issues with subaccount allocation.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/async-order
    • POST /trading/async-order/cancel
  • Impact: You will now receive a more specific error reason if an asynchronous order or its cancellation is rejected because of invalid account information in the allocation.

​

Stablecoin Conversion Creation Response Update

• Improved: The 201 Created response for the POST /stablecoins/conversion endpoint has been updated to support a new authorization workflow.
  • Category: Stablecoins
  • Endpoint Changed: POST /stablecoins/conversion
  • Impact: This is a breaking change. The response body for a successful conversion creation request now returns a required authorizationOperationId instead of conversionId. The conversionId is now optional in this response.
  • Additional Information: Use the new authorizationOperationId to track the authorization status of the stablecoin conversion request.

​

Added Interest Paydown and Accrual Operations for Collateral Management

• Improved: Added INTEREST_PAYDOWN and INTEREST_ACCRUAL as new valid actions for Collateral Management operations.
  • Category: Collateral Management
  • Endpoints Changed:
    • PATCH /collateral_management/operations/{operationId}
    • POST /collateral_management/operations
    • GET /collateral_management/operations
  • Impact: The action field in the request and response bodies for these endpoints now supports INTEREST_PAYDOWN and INTEREST_ACCRUAL as enum values. This enables users to programmatically record interest paydown and accrual activities on their exposures.
  • Additional Information: These new actions are valid for exposure operations, allowing for more detailed tracking of loan activities.

​

Added Support for Retrieving Statements

• Added new endpoints for listing and downloading account statements.
  • Category: Statements
  • Endpoints Added:
    • GET /statement-types: List available statement types.
    • GET /statements: List generated statements for your account.
    • GET /statements/{statementId}: Get details for a specific statement by its ID.
    • GET /statements/{statementId}/download: Download a specific statement file.
  • Impact: Users can now programmatically access and download their account statements, enhancing reporting and record-keeping capabilities.

​

Added Webhook Notifications for Real-Time Event Updates

• Added support for Webhook Notifications to receive real-time updates on account activity.
  • Type: Added
  • Description: Introduced a new set of endpoints for creating and managing webhook notifications. This allows clients to subscribe to specific events and receive real-time updates programmatically, eliminating the need for polling.
  • Category: Webhook Notifications
  • Endpoints Changed:
    • GET /webhook/validation-key
    • GET /webhook/event-types
    • POST /webhook/endpoints
    • GET /webhook/endpoints
    • GET /webhook/endpoints/{endpointId}
    • PATCH /webhook/endpoints/{endpointId}
    • POST /webhook/endpoints/{endpointId}/subscriptions
    • GET /webhook/endpoints/{endpointId}/subscriptions
    • DELETE /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId}
  • Methods: GET, POST, PATCH, DELETE
  • Impact: Users can now build more efficient and event-driven integrations by subscribing to notifications for events such as withdrawal.initiated or transfer.completed.
  • Example: To create a new webhook endpoint and subscribe it to an event, send a POST request to /webhook/endpoints:
    [
      {
        "url": "https://your-domain.com/transaction-webhooks",
        "description": "Endpoint for receiving transaction event webhooks",
        "subscriptions": [
          {
            "eventTypeId": "withdrawal.initiated"
          }
        ],
        "publicKey": "-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEeg+pxTCsjew/+7IK4+Vw5zyHDnMW7bzn\nsClhuYIKjXF8EJ1lfyZC2VPVullBKgvHRzNMfC1KkF2LIoRp2ibcWQ==\n-----END PUBLIC KEY-----"
      }
    ]
    
  • Additional Information: An API key with the Configure Webhooks permission is required to use these endpoints. You can retrieve a list of all available event types by calling the GET /webhook/event-types endpoint.

​

Enhanced Trading Orders with Subaccount Allocations

• Improved: Enhanced Trading endpoints to support and return subaccount allocation details.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/async-order
    • POST /trading/async-order/cancel
    • POST /trading/order
    • GET /trading/orders
    • GET /trading/orders/{orderId}
  • Request Body: The POST /trading/async-order endpoint now accepts a new allocation array in the request body, allowing you to specify how an order should be allocated across different subaccounts.
  • Response Body: The responses for all listed endpoints have been updated to include a detailed allocation object. This object provides granular information about how an order was allocated, including subaccountId, quantity, fee, and executionId.
  • Impact: This provides greater flexibility and transparency for users who manage multiple subaccounts, enabling programmatic allocation of orders and detailed reporting on executed trades.
  • Example: To allocate an async order, include the allocation array in your request:
    "allocation": [
      {
        "subaccountId": "343b6c83-6d91-4f13-9982-2109abd2dbb0",
        "quantity": "5000.00"
      },
      {
        "subaccountId": "905272f0-52f9-404e-b6cd-ad879e671790",
        "quantity": "5000.00"
      }
    ]
    

​

Clarified Gas Station Fee Option for Transfers and Withdrawals

• Improved the useGasStation parameter for handling network fees on transfers and withdrawals.
  • Category: Transactions, Transfers
  • Endpoints Changed:
    • POST /transactions/withdrawal
    • POST /transfers
  • Request Body: The optional boolean field useGasStation has been updated in the request body for creating transfers and withdrawals.
  • Impact: Setting useGasStation to true allows the Anchorage Digital gas station to pay for network fees, simplifying fee management for supported asset types and organizations. If the parameter is not included, it defaults to false.
  • Example:
    {
      "assetType": "ETH",
      "amount": "5.0",
      "idempotentId": "e8a7f9b0-9c8d-4e6f-a1b2-c3d4e5f6a7b8",
      "source": {
        "id": "1c920f4241b78a1d483a29f3c24b6c4c",
        "type": "WALLET"
      },
      "destination": {
        "id": "0x1234567890123456789012345678901234567890",
        "type": "ADDRESS"
      },
      "useGasStation": true
    }
    

​

Added Collect Endpoint and Enhanced Staking Operations

• Added a new transaction type and enhanced staking/unstaking requests.
  • Category: Transactions
  • Changes:
    • Added: A new endpoint POST /transactions/collect has been introduced to allow for the creation of collect requests.
    • Improved: The request bodies for POST /transactions/stake and POST /transactions/unstake have been updated to include a new optional boolean field, isFullAmount.
  • Impact: Users can now programmatically create collect requests. For staking and unstaking, setting isFullAmount to true will perform the operation for the full available amount, removing the need for clients to manually specify the quantity.

​

Added LTV Rounding Precision to Collateral Package Creation

• Added a new ltvRoundingPrecision field for specifying the number of decimal places to round Loan-to-Value (LTV) ratios.
  • Category: Collateral Management
  • Endpoint Changed: POST /collateral_management/packages
  • Request Body: The request body for creating a new collateral package now accepts the optional ltvRoundingPrecision field.
  • Impact: This provides greater control and precision over how LTV is calculated for new collateral packages.

​

Updated Stablecoin Conversion Request Body

• Improved: The request body for the POST /stablecoins/conversion endpoint has been updated to standardize how amounts and idempotency are handled.
  • Category: Stablecoins
  • Endpoint Changed: POST /stablecoins/conversion
  • Request Body Changes:
    • Removed: The optional fields decimalAmount and idempotentId have been removed.
    • Added: The following fields are now required:
      • amount (string): Specifies the conversion amount.
      • idempotencyKey (string): A client-provided key to ensure the request is processed only once.
  • Impact: This is a breaking change. Any integrations using this endpoint must be updated to send the new required fields amount and idempotencyKey.
  • Example:
    • Previous Request:
      {
        "decimalAmount": "100.00",
        "idempotentId": "some-uuid-v4-string",
        ...
      }
      
    • New Request:
      {
        "amount": "100.00",
        "idempotencyKey": "your-unique-key-string",
        ...
      }
      

​

Updated Trading and Quote Statuses

• Improved: The tradeStatus and quoteStatus fields across multiple Trading endpoints have been updated with more detailed descriptions and a comprehensive list of possible values.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/quote
    • POST /trading/quote/accept
    • GET /trading/settlements/{settlementId}/trades
    • GET /trading/trades
    • GET /trading/trades/{tradeId}
  • Impact: This change provides greater clarity on the lifecycle of trades and quotes. The responses for these endpoints will now reflect a more granular status. For instance, the tradeStatus field now includes the following possible values: PENDING, REJECTED, CANCELED, EXECUTED, SETTLING, SETTLED, PENDINGALLOCATION, and ALLOCATED.

​

Updates to Trading API Documentation

• Improved: Enhanced documentation for several Trading endpoints to provide clearer explanations, more detailed examples, and updated field descriptions.
  • Category: Trading
  • Endpoints Changed:
    • GET /trading/accounts/{accountId}
    • POST /trading/async-order
    • POST /trading/order
    • GET /trading/pairs
    • POST /trading/quote
    • POST /trading/quote/accept
    • GET /trading/settlements/{settlementId}/trades
    • GET /trading/trades
    • GET /trading/trades/{tradeId}
    • GET /trading/settlements
    • GET /trading/settlements/{settlementId}
  • Impact: These are documentation-only changes to improve clarity and provide better examples. There are no functional changes to the API endpoints.
  • Details:
    • Clarified descriptions for quoteStatus, tradeStatus, and settlementStatus across multiple endpoints to better define each state.
    • Added comprehensive request body examples for POST /trading/quote to illustrate BUY, SELL, and TWOWAY scenarios.
    • Improved the description for the allowedSlippage and vaultID fields in the POST /trading/quote/accept request body, including a detailed example of how allowedSlippage functions.
    • Updated the price field description across various trade-related endpoints to explain its composition and asynchronous availability.
    • Enhanced the description for the referenceData object returned by GET /trading/pairs.
    • Corrected and clarified response descriptions for 404 Not Found on GET /trading/accounts/{accountId} and GET /trading/settlements/{settlementId}/trades.

​

Added ‘OrderNotCancelable’ Reject Reason for Async Orders

• Improved: Added the OrderNotCancelable value to the rejectReason enum for asynchronous order responses.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/async-order
    • POST /trading/async-order/cancel
  • Impact: This change provides more specific feedback when an attempt to place or cancel an asynchronous order is rejected because the order is no longer in a state that can be modified (e.g., it has already been filled or canceled). The rejectReason field in the error response will now contain OrderNotCancelable in such cases.

​

Expanded Filtering Options for Listing Transactions

• Improved filtering for the List Transactions endpoint
  • Description: The types query parameter for the GET /transactions endpoint has been updated to support more granular filtering. You can now filter transactions by several new reward types.
  • Category: Transactions
  • Endpoint Changed: GET /transactions
  • Parameter Changed: The types query parameter now accepts the following new values: DELEGATION_REWARD, STAKING_REWARD, RESTAKING_REWARD, and ALLUVIAL_STAKING_REWARD.
  • Impact: Users can now retrieve a more specific list of transactions by filtering for various reward types, which helps in auditing and reconciling staking activities.
  • Example: To retrieve only staking and delegation rewards, you can make the following request:
    GET /v2/transactions?types=STAKING_REWARD,DELEGATION_REWARD
    

​

Comprehensive API Expansion for Custody, Automation, and Reporting

• Added: New endpoints for the Atlas Settlement Network, Collateral Management, Stablecoins, Tax Reporting, Trusted Destinations, and Webhook Notifications, alongside significant enhancements to core custody operations. This major update introduces a wide range of new capabilities to programmatically manage assets, automate workflows, and access detailed financial data.

• ​

  Atlas Settlement Network

  • Type: Added
  • Description: Introduced a suite of endpoints to manage participants, counterparties, and the full settlement lifecycle on the Atlas Settlement Network. This allows for proposing, accepting, authorizing, rejecting, and listing settlements programmatically.
  • Category: Atlas Settlement Network
  • Endpoints Added:
    • GET /atlas/directory/counterparties
    • GET /atlas/directory/counterparties/{counterpartyId}
    • GET /atlas/directory/participants
    • POST /atlas/settlements
    • GET /atlas/settlements
    • GET /atlas/settlements/{settlementId}
    • POST /atlas/settlements/{settlementId}/accept
    • POST /atlas/settlements/{settlementId}/authorize
    • POST /atlas/settlements/{settlementId}/reject

• ​

  Collateral Management

  • Type: Added
  • Description: Added new endpoints for creating and managing collateral packages, exposures, and financial operations. This enables programmatic tracking and updates of collateralized positions.
  • Category: Collateral Management
  • Endpoints Added:
    • GET /collateral_management/exposures
    • POST /collateral_management/exposures
    • GET /collateral_management/operations
    • POST /collateral_management/operations
    • PATCH /collateral_management/operations/{operationId}
    • GET /collateral_management/packages
    • POST /collateral_management/packages
    • PATCH /collateral_management/packages/{packageId}

• ​

  Stablecoins, Tax, and Trusted Destinations

  • Type: Added
  • Description: Introduced new endpoints to support stablecoin conversions, provide comprehensive tax reporting data, and manage trusted withdrawal destinations.
  • Categories: Stablecoins, Tax, Trusted Destinations
  • Endpoints Added:
    • POST /stablecoins/conversion: Create stablecoin conversions, including issuance and redemption.
    • GET /tax/inventory/summary/{subaccountId}, PATCH /tax/transaction/{transactionId}, GET /tax/clients/{customerId}/forms, and more: A full suite to fetch tax transactions, gains, inventory, forms, and update cost basis.
    • GET /trusted_destinations, POST /trusted_destinations, DELETE /trusted_destinations/{creationRequestId}/cancel, and more: Create, list, and manage the lifecycle of trusted destinations.

• ​

  Core Custody (Vaults, Wallets, Transactions, Transfers)

  • Type: Improved
  • Description: Significantly expanded capabilities for managing core custody operations. This update provides more granular control over wallets, addresses, and transactions, including staking and automated transfers.
  • Categories: Vaults, Wallets, Transactions, Transfers, Addresses
  • Endpoints Changed:
    • Vaults & Wallets: GET /vaults, POST /vaults/{vaultId}/wallets, GET /wallets, GET /wallets/{walletId}/staking/positions, and GET /wallets/{walletId}/staking/rewards for comprehensive listing and creation, including access to staking data.
    • Addresses: GET /vaults/{vaultId}/addresses and POST /wallets/{walletId}/addresses to list and provision new deposit addresses.
    • Transactions: POST /transactions/stake, POST /transactions/unstake, and POST /transactions/withdrawal to initiate staking and withdrawal operations.
    • Transfers: POST /transfers, GET /transfers, and DELETE /transfers/{transferId} to create, list, and cancel automated asset transfers.

• ​

  Webhook Notifications

  • Type: Added
  • Description: Introduced a complete set of endpoints for managing webhook notifications. Users can now create, update, and delete webhook endpoints, manage subscriptions to specific event types, and retrieve a validation key to ensure authenticity.
  • Category: Webhook Notifications
  • Endpoints Added:
    • GET /webhook/endpoints
    • POST /webhook/endpoints
    • GET /webhook/endpoints/{endpointId}
    • PATCH /webhook/endpoints/{endpointId}
    • GET /webhook/endpoints/{endpointId}/subscriptions
    • POST /webhook/endpoints/{endpointId}/subscriptions
    • DELETE /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId}
    • GET /webhook/event-types
    • GET /webhook/validation-key

​

Added Error Response for Exposure Creation

• Added: A 422 Unprocessable Entity error response was added to the endpoint for creating a new collateral exposure.
  • Category: Collateral Management
  • Endpoint Changed: POST /collateral_management/exposures
  • Impact: The API will now return a 422 status code if a request to create a collateral exposure is syntactically correct but cannot be processed due to semantic or business logic errors.

​

Added Endpoint for Stablecoin Conversions

• Added a new endpoint to enable programmatic conversion between stablecoins.
  • Category: Stablecoin Conversions
  • Endpoint Added:
    • POST /stablecoins/conversion - Create a Stablecoin Conversion
  • Impact: This new functionality allows users to convert between different stablecoins directly through the API.

​

Added Support for Trusted Destinations in Transfers and Withdrawals

• Added support for TRUSTED_DESTINATION as a valid destination type. This allows you to specify a pre-approved trusted destination when creating transfers and withdrawals.
  • Category: Transfers, Transactions
  • Endpoints Changed:
    • POST /transfers
    • POST /transactions/withdrawal
    • GET /transfers
    • GET /transfers/{transferId}
  • Request Body: The destination.type parameter in the request body for POST /transfers and POST /transactions/withdrawal now accepts the enum value TRUSTED_DESTINATION.
  • Impact: You can now initiate transfers and withdrawals to pre-configured trusted destinations by providing their unique ID, simplifying transactions to frequently used external addresses. The responses for GET /transfers and GET /transfers/{transferId} will also reflect this new destination type.
  • Example: To create a transfer to a trusted destination, you can now use a request body like this:
    {
      "assetType": "BTC",
      "amount": "1.5",
      "source": {
        "id": "3d293c0d64c703023692216e9b4f5280",
        "type": "WALLET"
      },
      "destination": {
        "id": "d1ae1416-ebd7-11ea-adc1-0242ac120002",
        "type": "TRUSTED_DESTINATION"
      }
    }
    

​

Updated Tax Inventory Response Field

• Improved
  • Updated the AverageUnitCost field to averageUnitCost in the tax inventory response for casing consistency.
  • Category: Tax
  • Endpoint Changed: GET /tax/inventory/{subaccountId}/{assetTypeId}
  • Impact: This is a breaking change. Integrations that parse the AverageUnitCost field will need to be updated to use the new averageUnitCost field name.
  • Example: Previous Response Field:
    {
      "AverageUnitCost": "50000.00"
    }
    
    New Response Field:
    {
      "averageUnitCost": "50000.00"
    }
    

​

New API Key Permission and Documentation Improvements

• Added
  • A new CONVERT_STABLECOINS permission has been added.
  • Category: API Key
  • Endpoint Changed: GET /apikey
  • Impact: The response from GET /apikey may now include CONVERT_STABLECOINS in the permissions array, if enabled for the API key.
• Improved
  • The documentation for the Api-Signature header parameter was updated for clarity.
  • Category: Transactions
  • Endpoints Changed:
    • POST /transactions/stake
    • POST /transactions/unstake
  • Impact: This is a documentation-only change to improve the readability of the signature construction example and does not affect API functionality.

​

Added Wallet Search by Address

• Added a new searchByAddress query parameter to the GET /wallets endpoint.
  • Category: Wallets
  • Description: This parameter allows you to find wallets by searching for a full or partial address contained within them.
  • Endpoint Changed: GET /wallets
  • Impact: Users can now more easily locate specific wallets by using an address as a search term.
  • Additional Information: The search requires a minimum of 3 characters.
  • Example: GET /v2/wallets?searchByAddress=0xAbC123

​

Added Strategy Parameters to Trading Order Responses

• Added a strategyParams object to the responses of the trading order endpoints to provide more details on strategy-based orders.
  • Category: Trading
  • Endpoints Changed:
    • GET /trading/orders
    • GET /trading/orders/{orderId}
  • Impact: This is a non-breaking change. The response for the listed endpoints will now include a strategyParams object containing the triggerPrice and endTime for applicable order types (e.g., stop-limit, take-profit).
  • Additional Information: The strategyParams object provides visibility into the parameters governing strategy-based orders.

​

Improved Error Handling for Collateral Package Creation

• Improved
  • Description: Added a new 422 Unprocessable Entity response to provide more specific error feedback when creating a new collateral package.
  • Category: Collateral Management
  • Endpoint Changed: POST /collateral_management/packages
  • Impact: API clients should now be prepared to handle the 422 Unprocessable Entity HTTP status code for this endpoint. This error indicates that while the request syntax is correct, the server cannot process the request due to semantic errors or failed business logic validations.

​

Added Endpoint to Cancel Trusted Destination Creation

• Added a new endpoint to cancel a pending Trusted Destination creation request.
  • Category: Trusted Destinations
  • Endpoint Changed: DELETE /trusted_destinations/{creationRequestId}/cancel
  • Impact: This provides users the ability to programmatically cancel a Trusted Destination creation workflow before it is finalized. This is useful for correcting errors or aborting requests that are no longer needed.
  • Additional Information: The creationRequestId in the path corresponds to the idempotentId provided in the initial POST /trusted_destinations request.

​

Standardized rejectReason Enum for Async Orders

• Improved: Standardized the rejectReason enum values for asynchronous trading orders to provide clearer, more consistent error codes.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/async-order
    • POST /trading/async-order/cancel
  • Impact: The rejectReason field in the response body for both placing and canceling async orders will now use a more standardized set of enum values. Clients who parse this field for specific error reasons should update their logic.
  • Additional Information:
    • The following enum values have been removed: ErrInvalidLimitPriceForSell, ErrInvalidLimitPriceForBuy, ErrInvalidTriggerPrice, ErrInvalidLimitPrice.
    • The following enum values have been added: InvalidLimitPrice, InvalidTriggerPrice.

​

Added New Reason for Async Order Rejection

• Improved: Added the ErrInvalidLimitPrice enum value to the rejectReason field in the responses for async order endpoints.
  • Category: Trading
  • Endpoints Changed:
    • POST /trading/async-order
    • POST /trading/async-order/cancel
  • Impact: When an async order is rejected due to an invalid limit price, the API response will now include this more specific reason, providing clearer feedback for failed order operations.

​

Added Detailed Balance Breakdown for Subaccounts

• Improved: The response for subaccount details now includes a granular breakdown of balances via a new entries field.
  • Category: Subaccounts
  • Endpoints Changed:
    • GET /subaccounts/customers/accounts
    • GET /subaccounts/customers/{customerId}/accounts
  • Details: Each object in the balances array of the response now contains an entries array. Each object within entries provides an amount and description for a specific component of the total balance (e.g., Posted, Pending).
  • Impact: This is a non-breaking change. Clients will receive additional, more detailed balance information in the API response.
  • Example of new entries field:
    "balances": [
      {
        "assetType": "USD",
        "totalBalance": "1000.00",
        "entries": [
          {
            "amount": "950.00",
            "description": "Posted Balance"
          },
          {
            "amount": "50.00",
            "description": "Pending Balance"
          }
        ]
      }
    ]
    

​

Deprecated VAULT Resource Type for Transfers and Withdrawals

• Deprecated
  • Description: The use of VAULT as a resource type for identifying the source and destination of funds is now deprecated. Users must specify a WALLET ID instead. This change applies when creating transfers and withdrawals, and the deprecation is also reflected in the responses of several related endpoints.
  • Category: Transfers, Transactions, Vaults, Wallets
  • Endpoints Changed:
    • POST /transactions/withdrawal
    • POST /transfers
    • GET /transfers
    • GET /transfers/{transferId}
    • GET /vaults
    • GET /vaults/{vaultId}
    • GET /vaults/{vaultId}/wallets
    • POST /vaults/{vaultId}/wallets
    • GET /wallets
    • GET /wallets/{walletId}
  • Request Body: For POST /transfers and POST /transactions/withdrawal, the source.type and destination.type fields no longer accept VAULT. You must now use WALLET.
  • Impact: Integrations that create transfers or withdrawals by specifying a VAULT ID must be updated to use a specific WALLET ID. This removes the previous behavior of defaulting to a vault’s default wallet.
  • Example:
    • Previous Request Body Snippet (No longer supported):
      {
        "source": {
          "id": "1c920f4241b78a1d483a29f3c24b6c4c",
          "type": "VAULT"
        },
        ...
      }
      
    • New Required Request Body Snippet:
      {
        "source": {
          "id": "3d293c0d64c703023692216e9b4f5280",
          "type": "WALLET"
        },
        ...
      }
      
  • Additional Information: This change ensures that all asset movements are explicit, removing the ambiguity of which wallet within a vault should be used. The relevant API responses have also been updated to reflect that a wallet’s resource type is always WALLET.

​

Updated Trusted Destinations Response

• Improved
  • Description: The response for listing trusted destinations has been updated to provide more detailed information. The owners array has been replaced by a more structured owner object, and new name and description fields have been added.
  • Category: Trusted Destinations
  • Endpoint Changed: GET /trusted_destinations
  • Impact: This is a breaking change. Integrations that previously parsed the owners array will need to be updated to use the new owner object.
  • Example:
    • Old Response:
      {
        "id": "td_123",
        "owners": ["cust_abc"]
      }
      
    • New Response:
      {
        "id": "td_123",
        "name": "My Destination",
        "description": "Coinbase wallet",
        "owner": {
          "id": "cust_abc",
          "type": "CUSTOMER"
        }
      }
      

​

Updated Async Order Parameters

• Improved: Changed the request body content type of the POST /trading/async-order endpoint.
  • Category: Trading
  • Endpoint Changed: /trading/async-order
  • Method: POST
  • Request Body: Content type changed to application/json. The parameters property is now specifically for STOP_LOSS, STOP_LIMIT, and TAKE_PROFIT_LIMIT order types. It includes optional endTime and required triggerPrice parameters.
  • Impact: Clarified the use of the parameters property and formalized the request body content type.

​

Updated Wallet Filtering Parameters

• Improved: Updated assetTypeId query parameter to assetType in the List all wallets for a vault endpoint.
  • Category: Wallets
  • Endpoint: /vaults/{vaultId}/wallets
  • Method: GET
  • Parameter Changed: assetTypeId replaced with assetType
• Improved: Updated assetTypeId query parameter to assetType in the List all wallets for all vaults endpoint.
  • Category: Wallets
  • Endpoint: /wallets
  • Method: GET
  • Parameter Changed: assetTypeId replaced with assetType

​

Added networkId and assetTypeId Filters to Wallet Endpoints

• Added networkId filter: If set, only wallets for this Network ID will be returned.
  • Category: Wallets
  • Endpoint: /vaults/{vaultId}/wallets
  • Method: GET
  • Path: /vaults/{vaultId}/wallets
  • Parameter: networkId in query
• Added assetTypeId filter: If set, only wallets for this Asset Type ID will be returned.
  • Category: Wallets
  • Endpoint: /vaults/{vaultId}/wallets
  • Method: GET
  • Path: /vaults/{vaultId}/wallets
  • Parameter: assetTypeId in query
• Added networkId filter: If set, only wallets for this Network ID will be returned.
  • Category: Wallets
  • Endpoint: /wallets
  • Method: GET
  • Path: /wallets
  • Parameter: networkId in query
• Added assetTypeId filter: If set, only wallets for this Asset Type ID will be returned.
  • Category: Wallets
  • Endpoint: /wallets
  • Method: GET
  • Path: /wallets
  • Parameter: assetTypeId in query

​

Added PATCH /collateral_management/packages/{packageId}

• Added new endpoint to update a collateral package
  • Category: Collateral Management
  • Endpoint: /collateral_management/packages/{packageId}
  • Method: PATCH
  • Path: /collateral_management/packages/{packageId}
  • Parameters: packageId (path parameter)
  • Request Body: The request body details are not specified in the diff.
  • Impact: Allows updating existing collateral packages.

​

Added RFQ Order Type to Trading Endpoints

• Added RFQ as a new order type.
  • Category: Trading
  • Endpoint: /trading/orders
  • Method: GET
  • Path: /trading/orders
  • Parameters: No new parameters added.
  • Request Body: N/A
  • Impact: orderType now includes RFQ as possible enum value.
• Added RFQ as a new order type.
  • Category: Trading
  • Endpoint: /trading/orders/{orderId}
  • Method: GET
  • Path: /trading/orders/{orderId}
  • Parameters: No new parameters added.
  • Request Body: N/A
  • Impact: orderType now includes RFQ as possible enum value.

​

Added RFQ Order Type to Trading Endpoints

• Added RFQ as a new order type to Trading endpoints.
  • Category: Trading Orders
  • Endpoints Changed:
    • GET /trading/orders
    • GET /trading/orders/{orderId}
  • Methods: GET
  • Paths:
    • /trading/orders
    • /trading/orders/{orderId}
  • Parameters: No new parameters added
  • Request Body: No changes to request bodies
  • Impact: The orderType field in the responses now includes RFQ as a possible value.
• Added RFQ enum value to the orderType property in the responses of the following endpoints:
  • GET /trading/orders
    • Impact: The list of returned orders can now include orders with the RFQ type.
  • GET /trading/orders/{orderId}
    • Impact: When retrieving a specific order, the orderType can now be RFQ.

​

Added Expired Status to Trusted Destinations Workflow

• Added Expired status to the Trusted Destination creation request workflow.
  • Category: Trusted Destinations
  • Endpoint: /trusted_destinations/{creationRequestId}/status
  • Method: GET
  • Path: /trusted_destinations/{creationRequestId}/status
  • Parameters: No parameters changed
  • Request Body: No request body
  • Impact: Adds Expired as a possible status for Trusted Destination creation requests.
  • Example: A response with status Expired indicates that the Trusted Destination creation request has expired.
  • Additional Information: No additional information.

​

Added Collateral Management Exposures Endpoint and Updated Collateral Management Packages Endpoint

• Added: Support for creating collateral exposures.
  • Category: Collateral Management
  • Endpoint Changed: /collateral_management/exposures
  • Method: POST
  • Path: /collateral_management/exposures
• Changed: Request body for creating collateral packages.
  • Category: Collateral Management
  • Endpoint Changed: /collateral_management/packages
  • Method: POST
  • Path: /collateral_management/packages
  • Request Body:
    • Removed required property internalName.
    • Changed property collateralAssetsConfig (array).

​

Added internalName and priceStrategy to Collateral Management Package Creation

• Added internalName property to POST /collateral_management/packages
  • Added an optional internal name for the collateral package, used for internal tracking and identification purposes.
  • Category: Collateral Management
  • Endpoint: /collateral_management/packages
  • Method: POST
  • Request Body Parameter: internalName (string)
• Added priceStrategy property to POST /collateral_management/packages
  • Added a required field specifying the pricing strategy to be used for the collateral package.
  • Category: Collateral Management
  • Endpoint: /collateral_management/packages
  • Method: POST
  • Request Body Parameter: priceStrategy (string)
  • Enum Value: DEFAULT

​

Updated Collateral Management Endpoints and Added Create Collateral Package Endpoint

• Added new endpoint to create collateral packages:
  • Category: Collateral Management
  • Endpoint Changed: POST /collateral_management/packages
  • Method: POST
  • Path: /collateral_management/packages
• Updated collateral package retrieval endpoint:
  • Category: Collateral Management
  • Endpoint Changed: GET /collateral_management/packages
  • Method: GET
  • Path: /collateral_management/packages
  • Response (200 OK):
    • application/json:
      • data:
        • acceleratedMarginCall: Added returnToLtv and warningLtv properties. Updated action enum to include NONE, PARTIAL, FULL, and SWEEP.
        • critical: Added returnToLtv and warningLtv properties. Updated action enum to include NONE, PARTIAL, FULL, and SWEEP.
        • marginCall: Added curePeriod, curePeriodProtection, and topUpType properties. Updated action enum to include NONE, PARTIAL, FULL, and SWEEP.
        • marginReturn: Added returnToLtv property. Updated action enum to include NONE and SWEEP.

​

Added GAS_STATION Transaction Type

• Added GAS_STATION as a new TransactionType enum value.
  • Category: Transactions
  • Endpoints Changed:
    • GET /transactions
    • GET /transactions/{transactionId}
  • Methods: GET
  • Paths:
    • /transactions
    • /transactions/{transactionId}
  • Parameters: No new parameters added
  • Request Body: No changes to request body
  • Impact: The transactionType field in the response now includes GAS_STATION as a possible value, representing funds received from the gas station to cover network fees.
  • Example: A transaction object might now include "transactionType": "GAS_STATION".
  • Additional Information: This addition provides more granular information about transaction types, allowing users to identify transactions related to gas fee payments.

​

Added Owners Field to Trusted Destinations Response

• Added owners field to Trusted Destinations response:
  • Category: Trusted Destinations
  • Endpoint Changed: GET /trusted_destinations
  • Method: GET
  • Path: /trusted_destinations
  • Parameters: No new parameters.
  • Request Body: No request body.
  • Impact: The response now includes an owners field in the data array, which is an array of strings representing the owners of the trusted destination.
  • Example:

{
  "data": [
    {
      "id": "some-id",
      "type": "crypto",
      "crypto": {
        "address": "some-address",
        "networkId": "some-network",
        "assetType": "some-asset",
        "isNetworkLevel": false
      },
      "owners": ["owner1", "owner2"]
    }
  ],
  "page": {
    "next": null
  }
}

• Additional Information: This change provides more information about the ownership of trusted destinations.

​

Added REHYPE_IN and REHYPE_OUT Operations for Collateral Management

• Added REHYPE_IN and REHYPE_OUT enum values to the action property: These new actions are available for collateral package operations.
  • Category: Collateral Management
  • Endpoints Changed:
    • POST /collateral_management/operations
    • PATCH /collateral_management/operations/{operationId}
    • GET /collateral_management/operations
  • Methods: POST, PATCH, GET
  • Paths:
    • /collateral_management/operations
    • /collateral_management/operations/{operationId}
  • Parameters: The action parameter in the request body now supports REHYPE_IN and REHYPE_OUT.
  • Request Body: The action property in the request body now includes REHYPE_IN and REHYPE_OUT as valid enum values.
  • Impact: Expands the available actions for collateral package operations. REHYPE_IN and REHYPE_OUT operations do not change the balance of the collateral package used for LTV monitoring.
• Updated description for action property: Clarified the valid actions for exposures and collateral packages, including the new REHYPE_IN and REHYPE_OUT actions, and noted that CLOSE_RETURN is not currently supported and write operations for liquidations are also not supported.
  • Category: Collateral Management
  • Endpoints Changed:
    • POST /collateral_management/operations
    • PATCH /collateral_management/operations/{operationId}
    • GET /collateral_management/operations
  • Methods: POST, PATCH, GET
  • Paths:
    • /collateral_management/operations
    • /collateral_management/operations/{operationId}
  • Parameters: No parameter changes.
  • Request Body: No request body changes.
  • Impact: Provides clearer documentation for the action property.

​

Updated Trusted Destination Statuses

• Improved GET /trusted_destinations/{creationRequestId}/status:
  • Category: Trusted Destinations
  • Endpoint: /trusted_destinations/{creationRequestId}/status
  • Method: GET
  • Changes: Updated the possible values for the status property in the 200 OK response. The new possible statuses provide more granularity into the Trusted Destination creation workflow.
  • Impact: Users will now receive more detailed status updates during the Trusted Destination creation process.
  • Example: The status property might return “Pending DocuSign Signature” during the signature step, or “Needs Quorum Approval” when the request is waiting for internal approvals.
  • New Statuses:
    • Initiated
    • Generating Docusign
    • Pending DocuSign Signature
    • Trusted Destination Operation In Progress
    • Needs Quorum Approval
    • Anchorage Risk Review
    • Linking Trusted Destination
    • Complete
    • Failed
    • Rejected
    • Canceled

​

Added Vesting Balances Endpoint

• Added new endpoint to get vesting balances for an allocation.
  • Category: Vesting
  • Endpoint: GET /vesting/balances/{allocationId}
  • Method: GET
  • Path: /vesting/balances/{allocationId}

​

Added Async Order Endpoint

• Added new endpoint to place async orders:
  • Category: Trading Orders
  • Endpoint: /trading/async-order
  • Method: POST
  • Description: Places an async order, either Market or Limit, currently only FillOrKill is supported. One of accountId or subaccountId must be specified, but not both.
  • Request Body: Similar to the request body of /trading/order, but designed for asynchronous order placement.
  • Impact: Enables placing orders asynchronously.
• Added STOP_LIMIT, TAKE_PROFIT_LIMIT, and STOP_LOSS enum values to the orderType property
  • Category: Trading
  • Endpoints Changed:
    • GET /trading/orders
    • GET /trading/orders/{orderId}
  • Methods: GET
  • Paths:
    • /trading/orders
    • /trading/orders/{orderId}
  • Parameters: orderType
  • Request Body: None
  • Impact: Expanded the range of order types available for trading.
  • Example: Users can now specify orderType as STOP_LIMIT, TAKE_PROFIT_LIMIT, or STOP_LOSS when placing or retrieving orders.
• Added: New endpoint to cancel an async order.
  • Category: Trading
  • Endpoint: /trading/async-order/cancel
  • Method: POST
  • Path: /trading/async-order/cancel
• Added: PENDING_CANCEL enum value to the orderStatus property.
  • Category: Trading
  • Endpoint: /trading/async-order
  • Method: POST
  • Path: /trading/async-order
  • Impact: This new status indicates that a cancellation request has been received for an async order.
• 
  
  • Added: New endpoint to cancel an async order.
    • Category: Trading
    • Endpoint: /trading/async-order/cancel
    • Method: POST
    • Path: /trading/async-order/cancel
  • Added: PENDING_CANCEL enum value to the orderStatus property.
    • Category: Trading
    • Endpoint: /trading/async-order
    • Method: POST
    • Path: /trading/async-order
    • Impact: This new status indicates that a cancellation request has been received for an async order.
• Added TWAP, VWAP, PEGGED, POV, and OTHER enum values to the orderType parameter.
  • Category: Trading Orders
  • Endpoint Changed: GET /trading/orders
  • Method: GET
  • Path: /trading/orders
  • Parameters: orderTypes
  • Impact: Expanded the possible values for filtering orders by type.
• Added TWAP, VWAP, PEGGED, POV, and OTHER enum values to the orderType property.
  • Category: Trading Orders
  • Endpoint Changed: GET /trading/orders/{orderId}
  • Method: GET
  • Path: /trading/orders/{orderId}
  • Impact: Expanded the returned order types.

​

Webhook Endpoint Updates

• Improved: Added publicKey to GET /webhook/endpoints responses.
  • Category: Webhook Notifications
  • Endpoint: GET /webhook/endpoints
  • Method: GET
  • Path: /webhook/endpoints
  • Parameters: No change
  • Request Body: No change
  • Impact: Responses now include the public key associated with each endpoint.
• Improved: Added publicKey to POST /webhook/endpoints requests.
  • Category: Webhook Notifications
  • Endpoint: POST /webhook/endpoints
  • Method: POST
  • Path: /webhook/endpoints
  • Parameters: No change
  • Request Body: Now includes an optional publicKey field.
  • Impact: Allows setting a public key when creating a webhook endpoint.
• Improved: Added publicKey to GET /webhook/endpoints/{endpointId} responses.
  • Category: Webhook Notifications
  • Endpoint: GET /webhook/endpoints/{endpointId}
  • Method: GET
  • Path: /webhook/endpoints/{endpointId}
  • Parameters: No change
  • Request Body: No change
  • Impact: Responses now include the public key associated with the endpoint.

• Added CONFIGURE_WEBHOOKS permission to API Key Permissions
  • Category: API Key
  • Endpoint: /apikey
  • Method: GET
  • Path: /apikey
  • Parameters: No parameters changed
  • Request Body: No request body
  • Impact: Adds a new permission option, CONFIGURE_WEBHOOKS, to the API key permissions enum.
  • Example: "permission": "CONFIGURE_WEBHOOKS" within the permissions array.
  • Additional Information: This new permission likely controls access to webhook configuration endpoints. Refer to the documentation for details on the specific functionality controlled by this permission.

• Added publicKey to GET /webhook/endpoints response
  • Category: Webhook Notifications
  • Endpoint Changed: /webhook/endpoints
  • Method: GET
  • Path: /webhook/endpoints
  • Parameters: No parameters changed
  • Request Body: Not applicable
  • Impact: Responses now include a publicKey property in the data array.
• Added publicKey to POST /webhook/endpoints request
  • Category: Webhook Notifications
  • Endpoint Changed: /webhook/endpoints
  • Method: POST
  • Path: /webhook/endpoints
  • Parameters: No parameters changed
  • Request Body: Requests now require a publicKey property in the array of items.
  • Impact: Clients must now provide a publicKey when creating webhook endpoints.
• Added publicKey to GET /webhook/endpoints/{endpointId} response
  • Category: Webhook Notifications
  • Endpoint Changed: /webhook/endpoints/{endpointId}
  • Method: GET
  • Path: /webhook/endpoints/{endpointId}
  • Parameters: No parameters changed
  • Request Body: Not applicable
  • Impact: Responses now include a publicKey property in the data object.
• Added publicKey to PATCH /webhook/endpoints/{endpointId} request
  • Category: Webhook Notifications
  • Endpoint Changed: /webhook/endpoints/{endpointId}
  • Method: PATCH
  • Path: /webhook/endpoints/{endpointId}
  • Parameters: No parameters changed
  • Request Body: Requests can now include a publicKey property.
  • Impact: Clients can now update the publicKey of a webhook endpoint.

​

Added Trusted Destinations Status Endpoint

• • Category: Trusted Destinations
  • Method: GET
  • Path: /trusted_destinations/{creationRequestId}/status
  • Parameters:
    • creationRequestId (path): Idempotent ID provided in the Create Trusted Destination request.
  • Impact: Allows users to track the progress of Trusted Destination creation requests.
  • Example: GET /trusted_destinations/1ca86e65-4340-4876-85f4-8334852b9c43/status would return the status of a Trusted Destination creation operation initiated with the idempotent ID 1ca86e65-4340-4876-85f4-8334852b9c43

​

Added Create Allocations Endpoint | Wealth Management

• Category: Subaccounts
• Endpoint: /subaccounts/transactions/allocations
• Method: POST
• Description: Create new allocations between subaccounts of the same Program Customer. This is a transactional operation, either all allocations are created successfully, or none are. If allocations are successfully created, any relevant pending subaccount transactions will be updated to reflect the allocations.
• Request Body: An array of allocations with their source and destination subaccount IDs, asset type, and amount. A maximum number of 100 allocations and 10 unique assets per request are enforced.
• Impact: Enables programmatic creation of allocations between subaccounts.
• Example:

{
  "allocations": [
    {
      "sourceSubaccountId": "source_subaccount_id_1",
      "destinationSubaccountId": "destination_subaccount_id_1",
      "assetType": "BTC",
      "amount": "1.5"
    },
    {
      "sourceSubaccountId": "source_subaccount_id_2",
      "destinationSubaccountId": "destination_subaccount_id_2",
      "assetType": "ETH",
      "amount": "10"
    }
  ]
}

​

Updated Create a Withdrawal Request endpoint

​

Release Date

​

Release Type

​

Summary

​

Background

1. Make Beneficiary and Destination fields fully optional (but not deprecated)
2. Adding a new field (non-breaking change) that will indicate if the caller wants to use the Trusted Destination or use the data submitted in the API:
   1. useTrustedDestinationAml: boolean
      1. true: System uses Trusted Destination information, no need to provide Beneficiary and Destination AML data
         1. false: Must provide Beneficiary and Destination AML data in the request.
   2. This field will be default false, to guarantee this is not a breaking change
3. For Wealth Management clients, originator information will be auto-populated by Anchorage when sourceType = SUBACCOUNT

​

New Requirements

• POST /v2/transactions/withdrawal

• SUBACCOUNT
• For joint-accounts additional field under source called CustomerId will be mandatory
• AML questionnaire requirements “Purpose” is required field

​

Examples

​

Standard Custody Withdrawals to Trusted Destinations

API Request: POST /v2/transactions/withdrawal
{
  "source": {
    "id":"4521431f758f18cab818ea4461a01ed7",
    "type":"VAULT"
  },
  "assetType": "ETH",
  "destination": {
    "id": "0x3F431f6259d8bCAa0695153bd141aF7265d086cd",
    "type": "ADDRESS"
  },
  "amount": "1",
  "description": "",
  "withdrawalAmlQuestionnaire": {
    "useTrustedDestinationAml": true,
    "purpose": "REBALANCE",
    "originatorType": "MY_ORGANIZATION"
  }
}

API Request: POST /v2/transactions/withdrawal
{
  "source": {
    "id":"4521431f758f18cab818ea4461a01ed7",
    "type":"Vault"
  },
  "assetType": "ETH",
  "destination": {
    "id": "0xf0Ed16EeedD8111B40De252467eE9d0E14cbfe99",
    "type": "ADDRESS"
  },
  "amount": "1",
  "description": "",
  "withdrawalAmlQuestionnaire": {
    "useTrustedDestinationAml": true,
    "purpose": "INTRA_COMPANY",
    "originatorType": "MY_CLIENT",
    "originatorName": "John Originator",
    "originatorCountry": "PT",
    "originatorStreetAddress": "Some Originator Street",
    "originatorPostalCode": "1111",
    "originatorCity": "Lisbon",
    "originatorStateProvince": "Lisbon"
  }
}

​

Wealth Management Withdrawal Requests

API Request: POST /v2/transactions/withdrawal
{
  "source": {
    "id":"15bb8b12-d991-45d2-b784-c83c4449265b",
    "type":"SUBACCOUNT"
  },
  "assetType": "ETH",
  "destination": {
    "id": "0x3F431f6259d8bCAa0695153bd141aF7265d086cd",
    "type": "ADDRESS"
  },
  "amount": "1",
  "description": "",
  "withdrawalAmlQuestionnaire": {
    "useTrustedDestinationAml": true,
    "purpose": "REBALANCE",
  }
}

​

Action Required

​

Products Impacted

​

Relevant Documentation

• Create a withdrawal request endpoint
• [Wealth Management] 5. Withdraw from a subaccount

​

Added Create Trusted Destinations Endpoint

​

Release Date

​

Release Type

​

Summary

​

Background & Details

• isNetworkLevel = true: e.g., ETH and USDC could be withdrawn to an ETH address.
• isNetworkLevel = False: e.g., Only ETH could be withdrawn to an ETH address.

​

New Permission Group

​

New Endpoints

• POST /v2/trusted_destinations

​

Examples

​

Create a new Trusted Destination

curl --request POST \
     --url https://api.anchorage-staging.com/v2/trusted_destinations \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "idempotentId": "YOUR_GENERATED_UUID_HERE",
  "trustedDestinations": [
    {
      "assetType": "ETH",
      "address": "0x430EF7FAB8e10dFb8B7c50c2026d0e247FEE4B8",
      "name": "Test Ethereum Address 3",
      "trustedDestinationAmlQuestionnaire": {
        "destinationType": "SELFHOSTED_WALLET",
        "selfhostedDescription": "Personal ETH wallet for testing",
        "selfhostedWalletOwner": "PERSON_OR_ENTITY",
        "recipientType": "PERSON",
        "recipientFirstName": "John",
        "recipientLastName": "Doe",
        "recipientFullName": "John Doe",
        "recipientCountry": "US",
        "recipientStreetAddress": "123 Main St",
        "recipientCity": "San Francisco",
        "recipientStateProvince": "CA",
        "recipientPostalCode": "94105"
      },
      "description": "Test Ethereum wallet for demo purposes",
      "memo": "ETH demo wallet 3",
      "isNetworkLevel": false
    },
    {
      "assetType": "ETH",
      "address": "0x3088D00C2CF28327DF06E53CA6D6A3b5642534bA",
      "name": "Test Ethereum Address 4",
      "trustedDestinationAmlQuestionnaire": {
        "destinationType": "SELFHOSTED_WALLET",
        "selfhostedDescription": "Organization ETH_R wallet",
        "selfhostedWalletOwner": "MY_ORGANIZATION",
        "recipientType": "MY_ORGANIZATION",
        "recipientFullName": "Demo Company Inc",
        "recipientCountry": "US",
        "recipientStreetAddress": "1 Market St",
        "recipientCity": "San Francisco",
        "recipientStateProvince": "CA",
        "recipientPostalCode": "94105"
      },
      "description": "Test ETH",
      "memo": "ETH wallet",
      "isNetworkLevel": true
    }
  ],
  "owner"://optional - only include for Wealth Management integrations
  {
    "type": "CUSTOMER",
    "id": "7266559476aac38fc8c7c2022f93a9d1b9b618b1c9e2b4387840b595dcd374aa"
  }
}

{
  "data": [
    {
      "crypto": {
        "address": "0x3088D00C2CF28327DF06E53CA6D6A3b5642534bE",
        "memo": "ETH wallet",
        "networkId": "ETH"
      },
      "id": "3157498769314373239",
      "type": "crypto"
    },
    {
      "crypto": {
        "address": "0x430EF7FAB8e10dFb8B7c50c2026d0e247FEE4B88",
        "assetType": "ETH",
        "memo": "ETH  wallet",
        "networkId": "ETH"
      },
      "id": "6728536440974950034",
      "type": "crypto"
    }
  ],
  "page": {
    "next": null
  }
}

​

Action Required

​

Products Impacted

• Token vesting integrations
• Wealth Management integration - Crypto Withdrawal flow.

​

Relevant Documentation

• Create Trusted Destination endpoint
• [Wealth Management integration] Step 5. Withdraw from a Subaccount

​

Template

​

Release Date

​

Release Type

​

Summary

​

Background

​

New Requirements

• POST /

​

Updated ..

​

Examples

​

​

Action Required

​

Products Impacted

​

Relevant Documentation

​

Onboarding API Updates | Wealth Management

​

Release Date

​

Release Type

​

Summary

​

Background

​

New Requirements

• POST /v2/onboarding/customers

• POST /v2/onboarding/accounts
• GET /v2/onboarding/accounts/{{subaccountId}}
• PUT /v2/onboarding/accounts/{{subaccountId}}
• POST /v2/onboardin/accounts/{{subaccountId}}/submit

​

Updated KYC Field Changes (Individual)

• physicalStateUS needs to be filled with the United States state 2 letter code when the physicalCountry is US.
• physicalStateOther needs to be filled with alphabetical characters when the physicalCountry is not US.
• New idType field that needs to have the value GOVERNMENT_ISSUED_ID_CARD or PASSPORT
  • If GOVERNMENT_ISSUED_ID_CARD the files that will need to be provided are idCardFront (step 2 and 3) and idCardBack (step 4 and 5)
  • If PASSPORT the files that will need to be provided is passportDocument (step 6 and 7)
• This fields have been removed on this new flow:
  • initialFundingMethod
  • sourceOfWealth
  • initialFundingWalletGroup

​

Updated KYC Field Changes (Institution)

• physicalStateUS needs to be filled with the United States state 2 letter code when the physicalCountry is US.
• physicalStateOther needs to be filled with alphabetical characters when the physicalCountry is not US.
• New hasDbaName that is a boolean value true or false
• New dbaNames is a text value that needs to be provided if hasDbaNameis true
• New upload field called constitutionDocument that is a required field (step 2 and 3)
• New upload field called proofOfAddressthat is required if hasProofOfAddress is true (step 4 and 5)
• These fields have been removed in the new flow:
  • legalStructure
  • customerType
  • countryOfIncorporation
  • legalRegistAddrDifPrincPlace and all related fields:
    • legalCountry
    • legalStreetAddress
    • legalCity
    • legalStateProvince
    • legalPostalCode
  • initialFundingWalletGroup
  • sourceOfWealth

​

New Account Opening Details

​

Examples

​

Updated - KYC Onboarding Example (Individual)

{
  "applicationType": "RIA_PC_INDIVIDUAL",
  "entries": [
	  { "key": "legalEntityName", "value": "RIA PC Inv 1 Test" },
	  { "key": "programCustomer",
		  "value": {
			  "firstName": "Kevin",
	      "lastName": "Flynn_1",
	      "dateOfBirth": "01/01/1970",
			  "email": "kevin.flynn_1@test.com",
			  "ssn": "123456789",
			  "physicalCity": "city",
			  "physicalCountry": "US",
			  "physicalPostalCode": "94104",
			  "physicalStateUS": "CA",
			  "physicalStreetAddress": "123 Lightcycle Way",
			  "idType": "GOVERNMENT_ISSUED_ID_CARD"
			}
		}
  ]
}

​

Updated - KYC Onboarding Example (Institution)

{
  "applicationType": "RIA_PC_INSTITUTION",
  "entries": [
    { "key": "legalEntityName", "value": "Encom LLC" },
    { "key": "hasDbaName", "value": true },
    { "key": "dbaNames", "value": "Encom Video Games" },
    { "key": "taxId", "value": "123456789" },
    { "key": "physicalCountry", "value": "US" },
    { "key": "physicalStreetAddress", "value": "123 Lightcycle Way" },
    { "key": "physicalCity", "value": "San Francisco" },
    { "key": "physicalStateUS", "value": "CA" },
    { "key": "physicalPostalCode", "value": "94104" },
    { "key": "hasProofOfAddress", "value": true }
  ]
}

​

Joint Account Example

{
    "name": "{{name}}",
    "externalId": "{{externalId}}",
    "submit": true,
    "entries": [
        { "key": "legalEntityName", "value": "SubAccount JOINT" },
        { "key": "accountType", "value": "JOINT" },
        { "key": "documentPreferenceAddressDefaultEmail", "value": "kevin.flynn_4@test.com" },
        { "key": "programSignerGroup", "value": [
                {
                    "programSignerFirstName": "Kevin",
                    "programSignerLastName": "Flynn_5",
                    "programSignerEmail": "kevin.flynn_5@test.com",
                    "termsAgreementId": "tersmAgreementId"
                },
                {
                    "programSignerFirstName": "Kevin",
                    "programSignerLastName": "Flynn_6",
                    "programSignerEmail": "kevin.flynn_6@test.com",
                    "termsAgreementId": "tersmAgreementId"
                }
            ]
        },
        { "key": "programCustomers", "value": [
                {
                    "programCustomerId": "{{customerId1}}",
                    "programCustomerRole": "PRIMARY"
                },
                {
                    "programCustomerId": "{{customerId2}}",
                    "programCustomerRole": "SECONDARY"
                }
            ]
        },
        { "key": "beneficiaryGroup", "value": [
                {
                    "beneficiaryType": "SPOUSE",
                    "beneficiaryName": "Test beneficiary",
                    "beneficiaryAllocation": "50"
                },
                {
                    "beneficiaryType": "CHARITY",
                    "beneficiaryName": "Test beneficiary 2",
                    "beneficiaryAllocation": "50"
                }
            ]
        },
        { "key": "fees", "value": [
                {
                    "feeType": "ADVISORY",
                    "feeRate": "0.1"
                },
                {
                    "feeType": "MANAGEMENT",
                    "feeRate": "0.25",
                    "feeIsBillable": true
                }
            ]
        }
    ]
}

​

Action Required

​

Products Impacted

​

Relevant Documentation

• Onboarding APIs
• Wealth Integration Guides
  • Individual
  • Institution
  • Create an Account

​

Added Collateral Management Packages Endpoint

• Added Collateral Management endpoints
  • Category: Collateral Management
  • Endpoint: /collateral_management/packages
  • Method: GET
  • Description: Added new properties to the /collateral_management/packages endpoint response to provide more detailed information about collateral package levels and their configurations. These new fields include marginReturn, marginCall, acceleratedMarginCall and critical objects, each containing properties such as ltv, action, returnToLtv, warningLtv, and defaultNotice. The critical object is now a required property.
  • Impact: Clients can now retrieve more detailed information about collateral packages and their configurations.\
    

​

Updated transactionId Parameter for Subaccount Tax Transactions | Wealth Management

• ImprovedtransactionId parameter description: When updating tax transactions with PATCH /tax/transaction/{transactionId} , this endpoint will now require the use of the ledger transactionId rather than the previous tax transaction id, which represented the Taxbit unique identifier.
• Category: Tax
• Endpoint Changed: /tax/transaction/{transactionId}
• Method: PATCH
• Parameter: transactionId in path

​

Removed Participant ID Parameter from Atlas Settlement Rejection Endpoint

• RemovedparticipantId parameter: The participantId parameter is no longer required in the query for the Reject a settlement proposal endpoint.
  • Category: Atlas Settlement Network
  • Endpoint Changed: POST /atlas/settlements/{settlementId}/reject
  • Method: POST
  • Path: /atlas/settlements/{settlementId}/reject
  • Parameters: Removed participantId from query parameters.
  • Impact: The server now infers the participant ID performing the rejection based on the provided API Key.

​

Added InvalidPrice Reject Reason to Trading Orders

• AddedInvalidPrice as a possible enum value for the rejectReason property
  • Category: Trading Orders
  • Endpoint: /trading/order
  • Method: POST
  • Impact: Orders can now be rejected with the InvalidPrice reason.
  • Description: Added InvalidPrice to the enum values for the rejectReason property in the response of the /trading/order POST endpoint. This provides a more specific reason for order rejection when the provided price is invalid.

​

Updated Subaccount Transaction Balances Array | Wealth Management

• Improvedamounts field in Subaccount Transaction responses: The amounts field within the subaccounts array now includes a balances array. This array provides a list of supported balance types for each asset and transaction, replacing the previous hold, pending, and posted properties.
  • Category: Subaccounts
  • Endpoints Changed:
    • GET /subaccounts/transactions
    • GET /subaccounts/transactions/{transactionsIds}
  • Impact: The response structure for these endpoints is now more flexible and informative, providing a clearer breakdown of balance types.
  • Example:

{
  "transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d",
  "subaccounts": [
    {
      "subaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf",
      "amounts": [
        {
          "assetType": "BTC",
          "balances": [
            {
              "amount": "1000.00",
              "balanceType": "POSTED"
            },
            {
              "amount": "500.00",
              "balanceType": "HOLD"
            }
          ]
        }
      ]
    }
  ]
}

​

Updated Parameters for Tax Forms Endpoint | Wealth Management

• Improved: Updated parameters for retrieving tax forms
  • Category: Tax
  • Endpoint Changed: GET /tax/clients/{affiliateId}/forms
  • Method Changed: GET
  • Path Changed: /tax/clients/{affiliateId}/forms to /tax/clients/{customerId}/forms
  • Parameters Changed:
    • Added customerId path parameter
    • Removed affiliateId path parameter
  • Impact: Users will now use customerId instead of affiliateId when retrieving tax forms.
• Example:

curl --request GET \
     --url https://api.anchorage-staging.com/v2/tax/clients/{customerId}/forms \
     --header 'accept: application/json'

​

Deprecated AML Questionnaire Fields for External Transfers API

​

Deprecated Destination and Beneficiary data from External Transfers API Payload

• Improved: Updated AML questionnaire to deprecate Destination and Beneficiary fields due to new enhancement where Anchorage pulls this data directly from the Trusted Destination.
  • Category: Transfers
  • Endpoint Changed: POST /transfers
  • Method: POST
  • Path: /transfers
  • Request Body Parameter: transferAmlQuestionnaire
    • Destination fields deprecated:
      • destinationType
      • institutionName
      • institutionCountry
      • selfhostedDescription
    • Beneficary fields deprecated:
      • recipientType
      • recipientFirstName
      • recipientLastName
      • recipientFullName
      • recipientCountry
      • recipientStreetAddress
      • recipientCity
      • recipientStateProvince
      • recipientPostalCode
    • Considering the previous fields deprecation all that needs to be sent now in the transferAmlQuestionnaire is the Purpose and Originator information
  • Impact: The transferAmlQuestionnaire Destination and Beneficiary information will now come directly from the AML answers associated with the respective trusted destination.
  • Documentation: See Create a Transfer API spec
• Example: