> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt
> Use this file to discover all available pages before exploring further.
# API Changelog (2025)
> Track updates, additions, and breaking changes to the Anchorage Digital API.
**Changelog by year:** [2026](/knowledge-base/api-reference/changelog) · [2025](/knowledge-base/api-reference/changelog-2025) · [2024](/knowledge-base/api-reference/changelog-2024)
## 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:
```json theme={null}
{
"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**:
```json theme={null}
{
"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**:
```json theme={null}
{
"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**:
```json theme={null}
{
"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**:
```bash theme={null}
curl --request GET \
--url 'https://api.anchorage.com/v2/delegation-addresses/ETH' \
--header 'Api-Access-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**:
```http theme={null}
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**:
```json theme={null}
{
"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`:
```json theme={null}
[
{
"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:
```json theme={null}
"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**:
```json theme={null}
{
"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**:
```json theme={null}
{
"decimalAmount": "100.00",
"idempotentId": "some-uuid-v4-string",
...
}
```
* **New Request**:
```json theme={null}
{
"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:
```json theme={null}
{
"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:*
```json theme={null}
{
"AverageUnitCost": "50000.00"
}
```
*New Response Field:*
```json theme={null}
{
"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**:
```json theme={null}
"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)**:
```json theme={null}
{
"source": {
"id": "1c920f4241b78a1d483a29f3c24b6c4c",
"type": "VAULT"
},
...
}
```
* **New Required Request Body Snippet**:
```json theme={null}
{
"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**:
```json theme={null}
{
"id": "td_123",
"owners": ["cust_abc"]
}
```
* **New Response**:
```json theme={null}
{
"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:**
```json theme={null}
{
"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}`
This is applicable only to vesting partners to whom Anchorage delivers an allocationId. For aggregate investor vesting balances, see `unvestedUnstakeableBalance` and `unvestedBalance` in any balance endpoint (ex: [GET v2/wallets](https://developers.anchorage.com/reference/getwallets))
## 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
**Added**: `/trusted_destinations/{creationRequestId}/status`
* * **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
**Added** `POST /subaccounts/transactions/allocations` endpoint to create new allocations.
* **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**:
```json theme={null}
{
"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 Date: April 17th, 2025
# Release Type
Technical – action required only for Withdrawal API and Wealth Management integrations.
# Summary
### Background
Client's who send assets to Trusted Destinations (whitelisted addresses) are currently required to submit duplicate AML information from a previously configured Trusted Destination as part of each Withdrawal request. With this update, Anchorage now references Trusted Destination destination information, you will only need to submit originator and purpose information (wealth clients will not need to submit originator).
**There are three main changes to the Withdrawals API**:
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
We have made **changes** to the following endpoints:
* `POST /v2/transactions/withdrawal`
We have **added** a new source type:
* `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
Originator `MY_ORGANIZATION`:
```json theme={null}
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"
}
}
```
Originator `MY_CLIENT`:
```json theme={null}
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
`sourceType`= `SUBACCOUNT`
```json theme={null}
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
No action required, unless you plan to use the additional field `useTrustedDestinationAml`. If so, please update the Withdrawal payload to match the specs identified above.
# Products Impacted
All withdrawal API requests and Wealth Management integrations.
# Relevant Documentation
* [Create a withdrawal request endpoint](https://developers.anchorage.com/reference/createwithdrawal)
* [\[Wealth Management\] 5. Withdraw from a subaccount](https://developers.anchorage.com/docs/6-withdrawing-assets-from-wealth-management-platform)
## Added Create Trusted Destinations Endpoint
# Release Date
Release Date: April 15th, 2025
# Release Type
Technical – action required only for Wealth and/or External Transfers or Withdrawal API users.
# Summary
### Background & Details
To simplify the Create Trusted Destination process for more programmatic use cases, we've enabled the ability to create trusted destinations via API. Each of these operations will require a quorum approval.
You may submit one or many destination addresses per upload (max = 10/per).
Each Trusted Destination can be applied to a specific asset address or to any asset on a specific network.
* `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.
For Wealth Management integrations, the Trusted Destinations will also be tied to an `owner` which represents a Wealth Management `CUSTOMER` (`id`= `customerId`). The `customer` object will not be available in the Web Dashboard for the initial release.
### New Permission Group
We have added a new permission group to the API Permission Group page to enable you "*Manage Trusted Destinations*". This is required to create a new Trusted Destination via API.
### New Endpoints
We have **added** the following endpoints:
* `POST /v2/trusted_destinations`
# Examples
### Create a new Trusted Destination
```json theme={null}
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"
}
}
```
**`GET v2/trusted_destinations`**
```json theme={null}
{
"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
No action required. This is an optional flow for creating Trusted Destinations.
# Products Impacted
* Token vesting integrations
* Wealth Management integration - Crypto Withdrawal flow.
# Relevant Documentation
* [Create Trusted Destination endpoint](https://developers.anchorage.com/reference/createtrusteddestinations)
* [\[Wealth Management integration\] Step 5. Withdraw from a Subaccount](https://developers.anchorage.com/docs/6-withdrawing-assets-from-wealth-management-platform)
## Template
# Release Date
Release Date: April 15th, 2025
# Release Type
Technical – action required only for applicable users.
# Summary
### Background
### New Requirements
We have made **changes** to the following endpoints:
We have **added** the following endpoints:
* POST /
### Updated ..
# Examples
###
```json theme={null}
```
# Action Required
Only for
# Products Impacted
TBD
# Relevant Documentation
TBD
## Onboarding API Updates | Wealth Management
# Release Date
Release Date: April 15th, 2025
# Release Type
Technical – action required only for applicable users.
# Summary
### Background
Anchorage is updating it's onboarding APIs to reduce the information necessary for client and account onboarding. We are also introducing a new suite of endpoints to enable the creation of "client accounts" (e.g. Joint account, Roth, etc.). These will reference the onboarding KYC profiles of end clients and will now contain some of the fields previosly included in the KYC application.
### New Requirements
We have made **changes** to the following endpoints:
* POST /v2/onboarding/customers
We have **added** the following endpoints:
* 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)
This step to create an individual program customer is very similar with the already existing flow. The differences are:
* `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)
This step to create an institution program customer is very similar with the already existing flow. The differences are:
* `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 `hasDbaName`is true
* New upload field called `constitutionDocument` that is a required field (step 2 and 3)
* New upload field called `proofOfAddress`that 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
| Account Type | Account Sub-type | Number of Program Customers | Type of Clients |
| :--------------------- | :---------------------------- | :-------------------------- | :-------------- |
| IRA | empty, ROLLOVER or CONVERSION | 1 | Individual |
| ROTH | empty, ROLLOVER or CONVERSION | 1 | Individual |
| JOINT | | 2 | Individual |
| CUSTODIAL | | 2 | Individual |
| INDIVIDUAL\_TAXABLE | | 1 | Individual |
| INSTITUTIONAL\_TAXABLE | | 1 | Institution |
# Examples
### Updated - KYC Onboarding Example (Individual)
```json theme={null}
{
"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)
```json theme={null}
{
"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
```json theme={null}
{
"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
Only for wealth management integration partners.
# Products Impacted
Wealth management integration.
# Relevant Documentation
* [Onboarding APIs](https://developers.anchorage.com/reference/createkycapplication)
* Wealth Integration Guides
* [Individual](https://developers.anchorage.com/docs/updated-onboarding-details-as-of-41525)
* [Institution](https://developers.anchorage.com/docs/updated-onboarding-details-institution)
* [Create an Account](https://developers.anchorage.com/docs/2-subaccounts-copy#integration-steps-overview)
## 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
* **Improved`transactionId` 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
* **Removed`participantId` 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
* **Added`InvalidPrice` 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
* **Improved`amounts` 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**:
```json theme={null}
{
"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 theme={null}
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](https://developers.anchorage.com/reference/createtransfer#/) spec
* **Example**:
```python python theme={null}
def create_external_transfer_with_aml(
amount,
asset_type,
sending_vault_id,
externalAddress,
aml_withdrawal_purpose,
aml_originator_type,
aml_originator_name="",
aml_originator_country="",
aml_originator_street_address="",
aml_originator_postal_code="",
aml_originator_city="",
aml_originator_state_province="",
transfer_memo="",
):
print_header("Creating external transfer...")
# purpose
aml_responses={"purpose": aml_withdrawal_purpose.upper()}
# originator
aml_responses["originatorType"] = aml_originator_type.upper()
if aml_originator_type.upper() == "MY_CLIENT":
aml_responses["originatorName"] = aml_originator_name
aml_responses["originatorCountry"] = aml_originator_country
aml_responses["originatorStreetAddress"] = aml_originator_street_address
aml_responses["originatorPostalCode"] = aml_originator_postal_code
aml_responses["originatorCity"] = aml_originator_city
aml_responses["originatorStateProvince"] = aml_originator_state_province
idempotent_id = uuid.uuid4().hex
transfer_params = {
"source": {"id": sending_vault_id, "type": "VAULT"},
"destination": {"id": externalAddress, "type": "ADDRESS"},
"assetType": asset_type,
"amount": amount,
"transferMemo": transfer_memo,
"idempotentId": idempotent_id,
"transferAmlQuestionnaire": aml_responses,
}
```
## Added Asset Parameters (on-chain asset tags or memos) for Transfers
* **Added** `assetParametersXRP` object to `/transfers` `POST` request body.
* This parameter provides additional options for XRP transfers.
* Includes `destinationTag` (integer) for identifying the recipient.
* **Added** `assetParametersXLM` object to `/transfers` `POST` request body.
* This parameter provides additional options for XLM transfers.
* Includes `memo` (string) for identifying the recipient.
* **Added** `assetParametersATOM` object to `/transfers` `POST` request body.
* This parameter provides additional options for ATOM transfers.
* Includes `memo` (string) for identifying the recipient.
* This field is deprecated, please migrate to using `assetParametersCosmos`.
* **Added** `assetParametersCosmos` object to `/transfers` `POST` request body.
* This parameter provides additional options for Cosmos blockchain transfers.
* Includes `memo` (string) for identifying the recipient.
* **Added** `assetParametersExtra` object to `/transfers` `POST` request body.
* This parameter provides extra options for other asset transfers.
* Includes `value` (string) for additional recipient information.
## Added New Tax Transaction Fields | Wealth Management
* **Added`receivedAsset`, `sentAsset`, and `feeAsset` properties to the `/tax/transactions/{subaccountId}` endpoint response.**
* **Category**: Tax
* **Endpoint Changed**: `GET /tax/transactions/{subaccountId}`
* **Method**: `GET`
* **Path**: `/tax/transactions/{subaccountId}`
* **Parameters**: No parameters changed
* **Request Body**: No request body
* **Impact**: The response now includes arrays of `receivedAsset`, `sentAsset`, and `feeAsset` objects, providing more detailed information about the assets involved in each tax transaction. The existing `received`, `sent`, and `fee` fields remain unchanged.
* **Example**: The `receivedAsset` array will contain objects with `assetType`, `costBasis`, and `quantity` properties for assets received in a deposit or trade. `sentAsset` will contain similar information for withdrawn or sold assets, and `feeAsset` will detail transaction fees.
* **Additional Information**: This change enhances the granularity of tax transaction data returned by the API, allowing for more comprehensive reporting and analysis.
## Updated Tax Endpoints | Wealth Management
* **Improved**: Updated the `/tax/transactions/{subaccountId}` endpoint's response for the `GET` method.
* **Category**: Tax
* **Endpoint Changed**: `/tax/transactions/{subaccountId}`
* **Method Changed**: `GET`
* **Parameter Changed**: `transactionTime`
* **Impact**: The `transactionTime` parameter now uses a consistent ISO-8601 format date time string.
* **Added**: Added `costBasisDate` parameter to the `/tax/gains/costbasis/{subaccountId}` endpoint's response for the `GET` method.
* **Category**: Tax
* **Endpoint Changed**: `/tax/gains/costbasis/{subaccountId}`
* **Method Changed**: `GET`
* **Parameter Added**: `costBasisDate`
* **Impact**: Returns the cost basis date in ISO-8601 format.
* **Improved**: Updated the `/tax/gains/costbasis/{subaccountId}` endpoint's response for the `GET` method.
* **Category**: Tax
* **Endpoint Changed**: `/tax/gains/costbasis/{subaccountId}`
* **Method Changed**: `GET`
* **Parameter Changed**: `saleDate`
* **Impact**: The `saleDate` parameter now uses a consistent ISO-8601 format date time string.
## Updated Subaccount Withdrawal Endpoint | Wealth Management
* **Improved subaccount withdrawal endpoints to include additional bank information fields.**
* **Category**: Subaccounts
* **Endpoints Changed**:
* `POST /subaccounts/{subaccountId}/fiat/withdrawals`
* `GET /subaccounts/{subaccountId}/fiat/withdrawals/{transactionId}`
* **Request Body Changes (`POST /subaccounts/{subaccountId}/fiat/withdrawals`):**
* Added `financialInstitution` object with nested properties:
* `address` (object with nested `address`, `address2`, `city`, `zipcode`, `state`, `country`)
* `name` (string)
* `id` (string)
* `code` (string, enum: ABA, BIC, DDA)
* Added `intermediateFinancialInstitution` object (same structure as `financialInstitution`)
* Moved `bankAccountNr` and `bankRoutingNr` inside the `beneficiary` object.
* Added `accountNumber` within the `beneficiary` object.
* Added `country` within the `beneficiary.address` object.
* Updated data types and descriptions for existing fields within the `beneficiary.address` object (`address`, `address2`, `city`, `zipcode`, `state`).
* **Response Changes (`GET /subaccounts/{subaccountId}/fiat/withdrawals/{transactionId}`):**
* Response now includes the updated `customerDetails` object reflecting the changes made to the request body.\
* **Impact**: Added the ability to add an “Intermediary Financial Institution” which allows withdrawals to international banks that require an intermediary financial institution in addition to the bank that the PC is depositing too.
* **Note** Not all international withdrawals require an intermediary institution.
## Added Gas Station | Atlas (ETH Only)
* **Added**: `useGasStation` property to the request body. This option allows users to request to use Gas Station to cover fees for the acceptor.
* **Category**: Atlas Settlement Network
* **Endpoint**: `POST /atlas/settlements/{settlementId}/accept`
* **Method**: POST
* **Path**: `/atlas/settlements/{settlementId}/accept`
* **Request Body Parameter**: `useGasStation` (boolean)
* **Added**: `useGasStation` property to the request body. This option allows users to request to use Gas Station to cover fees for the proposer.
* **Category**: Atlas Settlement Network
* **Endpoint**: `POST /atlas/settlements`
* **Method**: POST
* **Path**: `/atlas/settlements`
* **Request Body Parameter**: `useGasStation` (boolean)
* **Added**: `gasStationEnabled` property to the `proposerSide` object in the response. This indicates whether the Gas Station is enabled to cover fees for this participant. This can be null if the caller doesn't have access to this information.
* **Category**: Atlas Settlement Network
* **Endpoint**: `GET /atlas/settlements`
* **Method**: GET
* **Path**: `/atlas/settlements`
* **Response Parameter**: `data.proposerSide.gasStationEnabled` (boolean)
* **Added**: `gasStationEnabled` property to the `proposerSide` object in the response. This indicates whether the Gas Station is enabled to cover fees for this participant. This can be null if the caller doesn't have access to this information.
* **Category**: Atlas Settlement Network
* **Endpoint**: `GET /atlas/settlements/{settlementId}`
* **Method**: GET
* **Path**: `/atlas/settlements/{settlementId}`
* **Response Parameter**: `settlement.proposerSide.gasStationEnabled` (boolean)
## Updated Subaccount Transaction Endpoint | Wealth Management
* **Improved subaccount transaction creation**: The `/subaccounts/transactions` endpoint now accepts an array of transactions in the request body, allowing for the creation of multiple subaccount transactions in a single API call. This is a transactional operation; all transactions will be created successfully, or none will.
* **Category**: Subaccounts
* **Endpoint**: `POST /subaccounts/transactions`
* **Method**: POST
* **Request Body**:
* Added `transactions` (array of `CreateSubaccountTransaction` objects):
* `sourceSubaccountId` (string): Unique identifier for the source subaccount.
* `destinationSubaccountId` (string): Unique identifier for the destination subaccount.
* `assetType` (string): The asset type being transferred.
* `amount` (string): The amount to transfer.
* `transactionMemo` (string, optional): A memo to include with the transaction.
* `idempotentId` (string): A client-provided unique ID for idempotent transactions.
* Removed the following parameters, as they are now nested within each `CreateSubaccountTransaction` object in the `transactions` array: `sourceSubaccountId`, `destinationSubaccountId`, `assetType`, `amount`, `transactionMemo`, `idempotentId`.
* **Response (200 OK)**:
* `data`:
* Added `transactionIds` (array of `TransactionIdResponse` objects):
* `transactionId` (string): Unique identifier for the created transaction.
* `idempotentId` (string): Client-provided unique ID for the idempotent transaction.
* Removed: `transactionId` (string).
* **Impact**: Enables atomic creation of multiple subaccount transactions, enhancing efficiency.
* **Example Request**:
```json theme={null}
{
"transactions": [
{
"sourceSubaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf",
"destinationSubaccountId": "3eeaf765-0df2-49c9-9e1f-db9cf3e796dd",
"assetType": "BTC",
"amount": "1000.00",
"transactionMemo": "Transaction 1",
"idempotentId": "id1"
},
{
"sourceSubaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf",
"destinationSubaccountId": "3eeaf765-0df2-49c9-9e1f-db9cf3e796dd",
"assetType": "ETH",
"amount": "500.00",
"transactionMemo": "Transaction 2",
"idempotentId": "id2"
}
]
}
```
* **Example Response**:
```json theme={null}
{
"data": {
"transactionIds": [
{
"transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d",
"idempotentId": "id1"
},
{
"transactionId": "d5d6763e-1c18-4d4e-a4f9-966cbe18886e",
"idempotentId": "id2"
}
]
}
}
```
* **Additional Information**: This improvement streamlines the process of creating multiple subaccount transactions, reducing the number of API calls required.
## Added Tax Form Endpoints (account & subaccount) | Wealth Management
* **Added endpoint to get affiliate's generated tax forms:**
* **Category:** Tax
* **Endpoint:** `/tax/clients/{affiliateId}/forms`
* **Method:** `GET`
* **Path:** `/tax/clients/{affiliateId}/forms`
* **Parameters:** `affiliateId`
* **Request Body:** None
* **Impact:** Allows retrieval of affiliate tax forms.
* **Added endpoint to get subaccount's generated tax forms:**
* **Category:** Tax
* **Endpoint:** `/tax/subaccounts/{subaccountId}/forms`
* **Method:** `GET`
* **Path:** `/tax/subaccounts/{subaccountId}/forms`
* **Parameters:** `subaccountId`
* **Request Body:** None
* **Impact:** Allows retrieval of subaccount tax forms.
## Updated Tax Transaction Endpoint | Wealth Management
* **Improved`PATCH /tax/transaction/{transactionId}` endpoint**:
* **Category**: Tax
* **Endpoint Changed**: `/tax/transaction/{transactionId}`
* **Method**: PATCH
* **Path**: `/tax/transaction/{transactionId}`
* **Request Body**: Changed content type to `application/json`. Added optional `data` property containing nested `assetType` (string) and `lots` (array) properties. The `lots` array contains objects with `acquisitionDatetime` (string), `quantity` (string), and `cost` (string) properties.
* **Impact**: Allows updating cost basis information for tax transactions using a structured JSON payload with support for multiple tax lots.
* **Example**:
```json theme={null}
{
"assetType": "BTC",
"lots": [
{
"acquisitionDatetime": "2024-01-15T12:00:00Z",
"quantity": "1.0",
"cost": "20000"
},
{
"acquisitionDatetime": "2024-02-20T15:30:00Z",
"quantity": "0.5",
"cost": "11000"
}
],
"type": "DEPOSIT",
"acquisitionDatetime": "2024-03-05T09:45:00Z"
}
```
* **Additional Information**: This improvement provides a more robust and organized way to manage tax-related transaction data.
## Added Manual Billing Charges API | Wealth Management
* **Added Manual Billing Charge endpoints**
* **Category**: Subaccounts
* **Endpoints Changed**:
* `POST /subaccounts/billing/charges`
* `DELETE /subaccounts/billing/charges/{chargeId}`
* **Methods**: POST, DELETE
* **Paths**:
* `/subaccounts/billing/charges`
* `/subaccounts/billing/charges/{chargeId}`
* **Parameters**:
* `POST /subaccounts/billing/charges`:
* Request Body: `CreateSubaccountBillingChargesRequest` (includes `idempotentId`, `interval`, `feeType`, and `charges`)
* `DELETE /subaccounts/billing/charges/{chargeId}`:
* Path Parameter: `{chargeId}`
* **Impact**: Enables creating and canceling manual billing charges.
## Deposit Attribution API Enhancements
**Added two new query parameters`attributedAtStartDateTime` and `attributedAtEndDateTime` to filter deposit attributions by attribution date.**
* **Category**: Deposit Attribution
* **Endpoint**: `/deposit-attributions/attributions`
* **Method**: GET
* **Impact**: Users will be able to filter deposit attributions by attribution date.
* **Documentation**: [List Deposit Attributions API](https://docs.anchorage.com/reference/getdepositattributions)
**Also, added two new fields`blockchainTxId` and `assetType` to the deposit attribution response.**
* **Category**: Deposit Attribution
* **Endpoint**: `/deposit-attributions/attributions`
* **Method**: GET
* **Impact**: Users will be able to fetch the blockchain transaction ID and the asset type of the deposit associated with the attribution.
* **Documentation**: [List Deposit Attributions API](https://docs.anchorage.com/reference/getdepositattributions)