Skip to main content
Changelog by year: 2026 · 2025 · 2024
Improved

Improved Subaccount Transactions with Staking and Delegation Reward Types

Improved: Added two new transaction types, STAKING_REWARD and DELEGATION_REWARD, to provide more detailed transaction information for subaccounts involved in staking.Category: SubaccountsEndpoints Changed:
  • GET /subaccounts/transactions: Now supports filtering and returns the new STAKING_REWARD and DELEGATION_REWARD transaction types.
  • GET /subaccounts/transactions/{transactionsIds}: Response transactionType field now includes the new reward types.
  • GET /subaccounts/transactions/allocations: Response transactionType field now includes the new reward types.
Impact: This is a non-breaking additive change. The transactionType field in responses may now include STAKING_REWARD and DELEGATION_REWARD, and the types query parameter on GET /subaccounts/transactions now supports filtering by these new values, enabling more granular tracking of staking-related activity.Example:
Improved

Improved Rejection Reason for FillOrKill Trading Orders

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

Improved Staking Requests with Asset-Specific Parameters

Improved: The staking request endpoint now supports specific configuration parameters for different assets; the parameters field in the request body is now a structured object.Category: TransactionsEndpoint Changed:
  • POST /transactions/stake: The parameters field now accepts a structured object for asset-specific configurations, such as SOL and ETH staking parameters.
Impact: This change allows detailed, per-asset configuration of staking requests, enhancing flexibility and control. Support for these asset-specific parameters is still under active development.
Added

Added Asset-Specific Staking Parameters

Added a new parameters object to the request body for creating stake requests, allowing for asset-specific configurations.Category: TransactionsEndpoint Changed:
  • POST /transactions/stake: Request body now accepts a parameters object supporting stakingProvider (e.g. FIGMENT, BLOCKDAEMON), stakingProviderAddress, stakingPositionId, and validatorType (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

Added Talos as a Price Source Provider for Collateral Management

Added TALOS as a supported price source provider for Collateral Management.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/exposures: The priceSourceProvider field within assetTrackingConfig now accepts TALOS as a valid enum value.
  • POST /collateral_management/packages: The priceSourceProvider field within collateralAssetsConfig 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

Improved Stablecoin Conversion Field Descriptions

Improved: Clarified the descriptions for the sourceAssetType and destinationAssetType fields to provide clearer guidance for issuance and redemption operations.Category: StablecoinsEndpoint Changed:
  • POST /stablecoins/conversion: The description for sourceAssetType now states that for issuance the value must be USD, and for redemptions it must be the asset being redeemed; the description for destinationAssetType now states 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.
Improved

Improved Price Source Configuration for Collateral Management

Improved: Introduced a priceSourceProvider field to separate the pricing service provider from the underlying price source, and removed the KAMINO enum value from the priceSource field.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: Added priceSourceProvider to objects within collateralAssetsConfig; removed KAMINO from priceSource.
  • POST /collateral_management/exposures: Added priceSourceProvider to assetTrackingConfig; removed KAMINO from priceSource.
Impact: This change provides more granular control over pricing data by separating the service provider from the underlying price source. KAMINO is now specified via the new optional priceSourceProvider field instead of priceSource.
Improved

Improved Trading Statuses and Tax Tagging Responses

Improved: Added two new trading trade statuses and updated the response status code for asynchronous tax tagging operations.Category: Trading, TaxEndpoints Changed:
  • POST /trading/quote/accept: tradeStatus enum now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/trades: tradeStatus enum now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/trades/{tradeId}: tradeStatus enum now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/settlements/{settlementId}/trades: tradeStatus enum now includes PENDINGALLOCATION and ALLOCATED.
  • POST /tax/transaction/{transactionId}/tag: Now returns 202 Accepted to indicate the request is being processed rather than immediately complete.
  • DELETE /tax/transaction/{transactionId}/tag: Now returns 202 Accepted to indicate the request is being processed rather than immediately complete.
Impact: Trading responses now provide clearer insight into the allocation phase of a trade (PENDINGALLOCATION means a trade is awaiting client allocation, ALLOCATED means it is fully allocated). The tax tagging endpoints now more accurately reflect asynchronous processing with a 202 Accepted status rather than implying immediate completion.
Improved

Improved Collateral Management Price Sourcing with KAMINO

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

Added Price Staleness Configuration for Collateral Packages

Added an optional maxStalenessMinutes field to the request body for creating collateral packages, allowing configuration of the maximum age of an asset’s price before it is considered stale.Category: Collateral ManagementEndpoint Changed:
  • POST /collateral_management/packages: Each object within collateralAssetsConfig now accepts an optional integer maxStalenessMinutes field.
Impact: This is a non-breaking change. If maxStalenessMinutes is not provided, the system defaults to 3 minutes.Example:
Improved

Improved Vesting Balances Response with Asset Context

Improved: The response for getting vesting balances now includes externalTokenId and networkId for added asset context.Category: VestingEndpoint Changed:
  • GET /vesting/balances/{allocationId}: The balance object in the response now contains two new required fields: externalTokenId (the asset ID assigned by the external provider) and networkId (the blockchain network identifier).
Impact: This is a non-breaking additive change that provides more asset context in vesting balance responses.
Improved

Improved Trading Status Clarity and Added Tax Transaction Tagging

Improved: Added new endpoints for tagging tax transactions and expanded and clarified trading status fields.Category: Tax, TradingEndpoints Added:
  • POST /tax/transaction/{transactionId}/tag: Adds a tag to a transaction for tax purposes.
  • DELETE /tax/transaction/{transactionId}/tag: Removes a tag from a transaction.
Endpoints Changed:
  • POST /trading/quote: quoteStatus description clarified.
  • POST /trading/quote/accept: quoteStatus and tradeStatus descriptions clarified; tradeStatus now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/trades: tradeStatus description clarified and expanded.
  • GET /trading/trades/{tradeId}: tradeStatus description clarified and expanded.
  • GET /trading/settlements/{settlementId}/trades: tradeStatus description clarified and expanded.
Impact: Users can now organize transactions with tags for easier tax tracking and reporting. The addition of PENDINGALLOCATION and ALLOCATED trading statuses, along with clearer field descriptions, offers better visibility into the post-execution allocation process.
Added

Added stakeholderId Parameter to Vesting Balances Endpoint

Added an optional stakeholderId query parameter to the vesting balances endpoint.Category: VestingEndpoint Changed:
  • GET /vesting/balances/{allocationId}: New optional stakeholderId query parameter can be used to retrieve wallet information for a stakeholder.
Impact: This is a non-breaking change that improves the ability to retrieve wallet information for newly created stakeholders before any transactions have occurred.
Improved

Improved API Key Permissions with FIAT_BANKING

Improved: Added the FIAT_BANKING permission type.Category: API KeyEndpoint Changed:
  • GET /apikey: Response 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:
Improved

Improved Parameter Descriptions for Delegation Addresses

Improved: Updated the descriptions for parameters on the delegation addresses endpoint to provide better clarity.Category: TransactionsEndpoint Changed:
  • GET /delegation-addresses/{assetType}: 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

Added Endpoint for Listing Delegation Addresses

Added a new endpoint to list supported delegation addresses for staking.Category: TransactionsEndpoint Added:
  • GET /delegation-addresses/{assetType}: Retrieves a list of supported delegation addresses for a specific asset type.
Impact: Users can now programmatically discover available delegation addresses for a given asset before initiating staking operations. This endpoint requires the Initiate Staking and Unstaking permission.
Improved

Improved Delegation Address Details with Validator Information

Improved: The delegation addresses endpoint now includes additional details about the validator for each delegation address.Category: Delegation AddressesEndpoint Changed:
  • GET /delegation-addresses/{assetType}: Each address object in the data array now includes two new required fields: anchorageValidator (boolean) and validatorType (string).
Impact: These fields allow you to determine if a delegation address belongs to an Anchorage Digital validator and to identify the type of validator.Example:
Improved

Improved Collect Requests by Making Amount Optional

Improved: The amount field in the request body for creating a collect request is now optional.Category: TransactionsEndpoint Changed:
  • POST /transactions/collect: The amount property is no longer required.
Impact: You can now omit the amount field to collect the full inactive unstaked amount for a given staking position; if not specified, the request defaults to collecting the entire available amount.
Added

Added Endpoint to List Delegation Addresses

Added a new endpoint to list supported delegation addresses for a given asset type.Category: AddressesEndpoint Added:
  • GET /delegation-addresses/{assetType}: Lists supported delegation addresses for the specified asset type.
Impact: This allows users to programmatically discover valid delegation addresses for specific assets, which can be used to automate staking and delegation operations.Example:
Added

Added Endpoint to Update Customer Onboarding Applications

Added the ability to update existing customer onboarding applications before they are submitted for review.Category: OnboardingEndpoint Added:
  • PUT /onboarding/customers/{customerId}: Updates the data of an existing customer onboarding application by accepting an entries array of key-value pairs.
Impact: Users can now programmatically correct or add information to a customer’s onboarding application after initial creation but before final submission.Example:
Improved

Improved Collateral Exposures by Making Weight Optional

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

Improved Trading Statuses and Staking Full-Amount Operations

Improved: Added new trading statuses and enhanced unstake and collect operations with a full-amount option.Category: Trading, TransactionsEndpoints Changed:
  • POST /trading/quote: quoteStatus enum updated to consistently reflect the quote lifecycle (OPEN, REJECTED, EXECUTED).
  • POST /trading/quote/accept: tradeStatus now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/trades: tradeStatus now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/trades/{tradeId}: tradeStatus now includes PENDINGALLOCATION and ALLOCATED.
  • GET /trading/settlements/{settlementId}/trades: tradeStatus now includes PENDINGALLOCATION and ALLOCATED.
  • POST /transactions/unstake: The isFullAmount parameter description clarified to indicate it overrides any provided amount.
  • POST /transactions/collect: New isFullAmount boolean parameter added.
Impact: Clients can track when a trade is awaiting allocation versus fully allocated. You can now set isFullAmount: true for unstake and collect operations to process the full available balance, removing the need to first query for the exact amount.
Improved

Improved Staking Position Data and Trading Status Descriptions

Improved: Added the inactiveStakedAmount field to staking position responses and clarified the descriptions for trading status fields.Category: Wallets, TradingEndpoints Changed:
  • GET /wallets/{walletId}/staking/positions: Response now includes the numeric inactiveStakedAmount field (excluding units).
  • POST /trading/quote: quoteStatus description clarified.
  • POST /trading/quote/accept: quoteStatus and tradeStatus descriptions clarified, including the PENDINGALLOCATION and ALLOCATED states.
  • GET /trading/trades: tradeStatus description clarified.
  • GET /trading/trades/{tradeId}: tradeStatus description clarified.
  • GET /trading/settlements/{settlementId}/trades: tradeStatus description clarified.
Impact: Users can now retrieve the inactive staked amount for a given staking position for more detailed insight into staking activity. The trading status description updates are a non-breaking documentation enhancement that provides clearer explanations of the quote and trade lifecycle.
Improved

Improved Tax Form Responses with Additional Details

Improved: Enhanced tax form responses with additional details for each tax form.Category: TaxEndpoints Changed:
  • GET /tax/subaccounts/{subaccountId}/forms: Each form object now includes id, createdDate, year, revision, revisionType, and isFiled fields.
  • GET /tax/clients/{customerId}/forms: Each form object now includes id, createdDate, year, revision, revisionType, and isFiled fields.
Impact: This is a non-breaking change that provides richer data for tax form management and tracking.Example:
Improved

Improved Descriptions for Creating Trusted Destinations

Improved: Updated the descriptions for fields in the request body to provide better clarity.Category: Trusted DestinationsEndpoint Changed:
  • POST /trusted_destinations: Descriptions for the trustedDestinations array and the name property within array items have been improved.
Impact: This is a non-breaking documentation change to improve developer experience. No functional changes have been made.
Improved

Improved Collect Request Body with Source and Idempotency

Improved: The request body for creating a collect request now includes source, description, and an idempotency key.Category: TransactionsEndpoint Changed:
  • POST /transactions/collect: Request body now requires a source object specifying the wallet to collect from, and adds optional description and idempotentId fields. The 201 Created response now returns an application/json payload.
Impact: This is a breaking change — the source field is now required. Clients using this endpoint must update their integration to include the source object.
Improved

Improved Error Handling for Asynchronous Orders

Improved: Added the InvalidAccountsInAllocation reject reason for asynchronous orders that fail due to subaccount allocation issues.Category: TradingEndpoints Changed:
  • POST /trading/async-order: Response rejectReason now includes InvalidAccountsInAllocation.
  • POST /trading/async-order/cancel: Response rejectReason now includes InvalidAccountsInAllocation.
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.
Improved

Improved Stablecoin Conversion Creation Response

Improved: The 201 Created response for creating a stablecoin conversion now supports a new authorization workflow.Category: StablecoinsEndpoint Changed:
  • POST /stablecoins/conversion: The response now returns a required authorizationOperationId instead of conversionId; conversionId is now optional in the response.
Impact: This is a breaking change. Use the new authorizationOperationId to track the authorization status of the stablecoin conversion request.
Improved

Improved Collateral Management with Interest Paydown and Accrual Actions

Improved: Added INTEREST_PAYDOWN and INTEREST_ACCRUAL as new valid actions for Collateral Management operations.Category: Collateral ManagementEndpoints Changed:
  • PATCH /collateral_management/operations/{operationId}: action field now supports INTEREST_PAYDOWN and INTEREST_ACCRUAL.
  • POST /collateral_management/operations: action field now supports INTEREST_PAYDOWN and INTEREST_ACCRUAL.
  • GET /collateral_management/operations: action field in responses now supports INTEREST_PAYDOWN and INTEREST_ACCRUAL.
Impact: This enables users to programmatically record interest paydown and accrual activities on their exposures, allowing for more detailed tracking of loan activities.
Added

Added Endpoints for Retrieving Account Statements

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

Added Webhook Notifications for Real-Time Event Updates

Added support for Webhook Notifications to receive real-time updates on account activity.Category: Webhook NotificationsEndpoints Added:
  • GET /webhook/validation-key: Retrieves the key used to validate webhook payload signatures.
  • GET /webhook/event-types: Lists all available event types you can subscribe to.
  • POST /webhook/endpoints: Creates a new webhook endpoint.
  • GET /webhook/endpoints: Lists your webhook endpoints.
  • GET /webhook/endpoints/{endpointId}: Gets a specific webhook endpoint.
  • PATCH /webhook/endpoints/{endpointId}: Updates a webhook endpoint.
  • POST /webhook/endpoints/{endpointId}/subscriptions: Subscribes an endpoint to an event type.
  • GET /webhook/endpoints/{endpointId}/subscriptions: Lists an endpoint’s event subscriptions.
  • DELETE /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId}: Removes an endpoint’s subscription to an event type.
Impact: Users can now build more efficient, event-driven integrations by subscribing to notifications for events such as withdrawal.initiated or transfer.completed, eliminating the need for polling. An API key with the Configure Webhooks permission is required to use these endpoints.Example:
Improved

Improved Trading Orders with Subaccount Allocation Details

Improved: Trading endpoints now support and return subaccount allocation details.Category: TradingEndpoints Changed:
  • POST /trading/async-order: Request body now accepts an allocation array specifying how the order should be allocated across subaccounts.
  • POST /trading/async-order/cancel: Response now includes a detailed allocation object.
  • POST /trading/order: Response now includes a detailed allocation object.
  • GET /trading/orders: Response now includes a detailed allocation object.
  • GET /trading/orders/{orderId}: Response now includes a detailed allocation object.
Impact: This provides greater flexibility and transparency for users managing multiple subaccounts, enabling programmatic allocation of orders and detailed reporting on executed trades. The allocation object includes subaccountId, quantity, fee, and executionId.Example:
Improved

Improved Gas Station Fee Option for Transfers and Withdrawals

Improved: Clarified the useGasStation parameter for handling network fees on transfers and withdrawals.Category: Transactions, TransfersEndpoints Changed:
  • POST /transactions/withdrawal: The optional boolean useGasStation field is now more clearly documented.
  • POST /transfers: The optional boolean useGasStation field is now more clearly documented.
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 omitted, it defaults to false.Example:
Added

Added Collect Endpoint and Improved Staking Operations

Added a new transaction type for collect requests and enhanced staking and unstaking requests with a full-amount option.Category: TransactionsEndpoint Added:
  • POST /transactions/collect: Creates a collect request.
Endpoints Changed:
  • POST /transactions/stake: Request body now accepts an optional boolean isFullAmount field.
  • POST /transactions/unstake: Request body now accepts an optional boolean isFullAmount field.
Impact: Users can now programmatically create collect requests. Setting isFullAmount to true on stake and unstake requests performs the operation for the full available amount, removing the need for clients to manually specify the quantity.
Added

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 ManagementEndpoint Changed:
  • POST /collateral_management/packages: Request body now accepts an optional ltvRoundingPrecision field.
Impact: This provides greater control and precision over how LTV is calculated for new collateral packages.
Improved

Improved Stablecoin Conversion Request Body

Improved: Standardized how amounts and idempotency are handled when creating a stablecoin conversion.Category: StablecoinsEndpoint Changed:
  • POST /stablecoins/conversion: Removed the optional decimalAmount and idempotentId fields; added required fields amount (string) and idempotencyKey (string).
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 Structure:
New Request Structure:
Improved

Improved Trading and Quote Status Descriptions

Improved: Updated the tradeStatus and quoteStatus fields across multiple Trading endpoints with more detailed descriptions and a comprehensive list of possible values.Category: TradingEndpoints Changed:
  • POST /trading/quote: quoteStatus description expanded.
  • POST /trading/quote/accept: tradeStatus and quoteStatus descriptions expanded.
  • GET /trading/settlements/{settlementId}/trades: tradeStatus description expanded.
  • GET /trading/trades: tradeStatus description expanded.
  • GET /trading/trades/{tradeId}: tradeStatus description expanded.
Impact: This change provides greater clarity on the lifecycle of trades and quotes. The tradeStatus field now documents the following possible values: PENDING, REJECTED, CANCELED, EXECUTED, SETTLING, SETTLED, PENDINGALLOCATION, and ALLOCATED.
Improved

Improved Trading API Documentation Clarity

Improved: Enhanced documentation for several Trading endpoints with clearer explanations, more detailed examples, and updated field descriptions.Category: TradingEndpoints Changed:
  • GET /trading/accounts/{accountId}: Clarified 404 Not Found response description.
  • POST /trading/async-order: Description clarity improvements.
  • POST /trading/order: Description clarity improvements.
  • GET /trading/pairs: Enhanced description of the referenceData object.
  • POST /trading/quote: Added comprehensive request body examples for BUY, SELL, and TWOWAY scenarios; clarified quoteStatus description.
  • POST /trading/quote/accept: Improved description of allowedSlippage and vaultID, including a detailed example of how allowedSlippage functions.
  • GET /trading/settlements/{settlementId}/trades: Clarified tradeStatus and settlementStatus descriptions and the 404 Not Found response.
  • GET /trading/trades: Clarified tradeStatus description.
  • GET /trading/trades/{tradeId}: Clarified tradeStatus description.
  • GET /trading/settlements: Clarified settlementStatus description.
  • GET /trading/settlements/{settlementId}: Clarified settlementStatus description; updated price field description to explain its composition and asynchronous availability.
Impact: These are documentation-only changes to improve clarity and provide better examples. There are no functional changes to the API endpoints.
Improved

Improved Async Order Rejection with OrderNotCancelable Reason

Improved: Added the OrderNotCancelable value to the rejectReason enum for asynchronous order responses.Category: TradingEndpoints Changed:
  • POST /trading/async-order: rejectReason now includes OrderNotCancelable.
  • POST /trading/async-order/cancel: rejectReason now includes OrderNotCancelable.
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 modifiable state (e.g., already filled or canceled).
Improved

Improved Transaction Filtering with New Reward Types

Improved: The types query parameter for listing transactions now supports more granular filtering by reward type.Category: TransactionsEndpoint Changed:
  • GET /transactions: The types query parameter now accepts 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:
Added

Added Atlas Settlement Network, Collateral Management, Stablecoins, Tax, Trusted Destinations, and Webhook Endpoints

Added a broad set of new endpoints spanning the Atlas Settlement Network, Collateral Management, Stablecoins, Tax Reporting, Trusted Destinations, and Webhook Notifications, alongside significant enhancements to core custody operations for vaults, wallets, transactions, and transfers.Category: Atlas Settlement Network, Collateral Management, Stablecoins, Tax, Trusted Destinations, Webhook Notifications, CustodyEndpoints Added:
  • GET /atlas/directory/counterparties: Lists counterparties on the Atlas Settlement Network.
  • GET /atlas/directory/counterparties/{counterpartyId}: Gets a specific counterparty.
  • GET /atlas/directory/participants: Lists participants on the Atlas Settlement Network.
  • POST /atlas/settlements: Proposes a new settlement.
  • GET /atlas/settlements: Lists settlements.
  • GET /atlas/settlements/{settlementId}: Gets a specific settlement.
  • POST /atlas/settlements/{settlementId}/accept: Accepts a settlement proposal.
  • POST /atlas/settlements/{settlementId}/authorize: Authorizes a settlement.
  • POST /atlas/settlements/{settlementId}/reject: Rejects a settlement proposal.
  • GET /collateral_management/exposures: Lists collateral exposures.
  • POST /collateral_management/exposures: Creates a collateral exposure.
  • GET /collateral_management/operations: Lists collateral operations.
  • POST /collateral_management/operations: Creates a collateral operation.
  • PATCH /collateral_management/operations/{operationId}: Updates a collateral operation.
  • GET /collateral_management/packages: Lists collateral packages.
  • POST /collateral_management/packages: Creates a collateral package.
  • PATCH /collateral_management/packages/{packageId}: Updates a collateral package.
  • POST /stablecoins/conversion: Creates 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 of endpoints to fetch tax transactions, gains, inventory, and forms, and to 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.
  • GET /webhook/endpoints: Lists webhook endpoints.
  • POST /webhook/endpoints: Creates a webhook endpoint.
  • GET /webhook/endpoints/{endpointId}: Gets a webhook endpoint.
  • PATCH /webhook/endpoints/{endpointId}: Updates a webhook endpoint.
  • GET /webhook/endpoints/{endpointId}/subscriptions: Lists an endpoint’s subscriptions.
  • POST /webhook/endpoints/{endpointId}/subscriptions: Subscribes an endpoint to an event type.
  • DELETE /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId}: Removes an event subscription.
  • GET /webhook/event-types: Lists available webhook event types.
  • GET /webhook/validation-key: Retrieves the webhook payload validation key.
Endpoints Changed:
  • GET /vaults, POST /vaults/{vaultId}/wallets, GET /wallets, GET /wallets/{walletId}/staking/positions, GET /wallets/{walletId}/staking/rewards: Expanded for comprehensive listing and creation, including access to staking data.
  • GET /vaults/{vaultId}/addresses, POST /wallets/{walletId}/addresses: Expanded to list and provision new deposit addresses.
  • POST /transactions/stake, POST /transactions/unstake, POST /transactions/withdrawal: Expanded to initiate staking and withdrawal operations.
  • POST /transfers, GET /transfers, DELETE /transfers/{transferId}: Expanded to create, list, and cancel automated asset transfers.
Impact: This major update introduces a wide range of new capabilities to programmatically manage assets, automate workflows, and access detailed financial data across custody, settlement, collateral, stablecoin, tax, and webhook operations.
Added

Added 422 Error Response for Collateral Exposure Creation

Added a 422 Unprocessable Entity error response to the endpoint for creating a new collateral exposure.Category: Collateral ManagementEndpoint Changed:
  • POST /collateral_management/exposures: May now return a 422 Unprocessable Entity response when a request is syntactically correct but cannot be processed due to semantic or business logic errors.
Impact: API clients should be prepared to handle this new 422 status code for this endpoint.
Added

Added Endpoint for Stablecoin Conversions

Added a new endpoint to enable programmatic conversion between stablecoins.Category: Stablecoin ConversionsEndpoint Added:
  • POST /stablecoins/conversion: Creates a stablecoin conversion.
Impact: This new functionality allows users to convert between different stablecoins directly through the API.
Added

Added Trusted Destination Support for Transfers and Withdrawals

Added support for TRUSTED_DESTINATION as a valid destination type, allowing you to specify a pre-approved trusted destination when creating transfers and withdrawals.Category: Transfers, TransactionsEndpoints Changed:
  • POST /transfers: destination.type now accepts TRUSTED_DESTINATION.
  • POST /transactions/withdrawal: destination.type now accepts TRUSTED_DESTINATION.
  • GET /transfers: Response now reflects the TRUSTED_DESTINATION destination type.
  • GET /transfers/{transferId}: Response now reflects the TRUSTED_DESTINATION destination type.
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.Example:
Improved

Improved Tax Inventory Response Field Casing

Improved: Updated the AverageUnitCost field to averageUnitCost in the tax inventory response for casing consistency.Category: TaxEndpoint Changed:
  • GET /tax/inventory/{subaccountId}/{assetTypeId}: Response field renamed from AverageUnitCost to averageUnitCost.
Impact: This is a breaking change. Integrations that parse the AverageUnitCost field must be updated to use the new averageUnitCost field name.Example:Previous Response Structure:
New Response Structure:
Improved

Improved API Key Permissions and Signature Documentation

Improved: Added a new API key permission for converting stablecoins and clarified signature header documentation for staking endpoints.Category: API Key, TransactionsEndpoints Changed:
  • GET /apikey: Response permissions array may now include the new CONVERT_STABLECOINS permission.
  • POST /transactions/stake: Api-Signature header documentation clarified.
  • POST /transactions/unstake: Api-Signature header documentation clarified.
Impact: The CONVERT_STABLECOINS permission may now appear in GET /apikey responses if enabled for the API key. The signature header documentation update is documentation-only and does not affect API functionality.
Added

Added Wallet Search by Address

Added a new searchByAddress query parameter to find wallets by a full or partial address they contain.Category: WalletsEndpoint Changed:
  • GET /wallets: New searchByAddress query parameter, requiring a minimum of 3 characters.
Impact: Users can now more easily locate specific wallets by using an address as a search term.Example:
Added

Added Strategy Parameters to Trading Order Responses

Added a strategyParams object to trading order responses to provide more detail on strategy-based orders.Category: TradingEndpoints Changed:
  • GET /trading/orders: Response now includes a strategyParams object containing triggerPrice and endTime for applicable order types.
  • GET /trading/orders/{orderId}: Response now includes a strategyParams object containing triggerPrice and endTime for applicable order types.
Impact: This is a non-breaking change that provides visibility into the parameters governing strategy-based orders (e.g., stop-limit, take-profit).
Improved

Improved Error Handling for Collateral Package Creation

Improved: Added a new 422 Unprocessable Entity response to provide more specific error feedback when creating a new collateral package.Category: Collateral ManagementEndpoint Changed:
  • POST /collateral_management/packages: May now return a 422 Unprocessable Entity response.
Impact: API clients should be prepared to handle the 422 Unprocessable Entity status code, which indicates the request syntax is correct but the server cannot process it due to semantic errors or failed business logic validation.
Added

Added Endpoint to Cancel Trusted Destination Creation

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

Improved Standardization of rejectReason Enum for Async Orders

Improved: Standardized the rejectReason enum values for asynchronous trading orders to provide clearer, more consistent error codes.Category: TradingEndpoints Changed:
  • POST /trading/async-order: rejectReason enum standardized — removed ErrInvalidLimitPriceForSell, ErrInvalidLimitPriceForBuy, ErrInvalidTriggerPrice, and ErrInvalidLimitPrice; added InvalidLimitPrice and InvalidTriggerPrice.
  • POST /trading/async-order/cancel: Same rejectReason enum changes as above.
Impact: Clients who parse the rejectReason field for specific error reasons should update their logic to use the new enum values.
Improved

Improved Async Order Rejection with ErrInvalidLimitPrice Reason

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

Improved Subaccount Balances with Detailed Entry Breakdown

Improved: Subaccount details responses now include a granular breakdown of balances via a new entries field.Category: SubaccountsEndpoints Changed:
  • GET /subaccounts/customers/accounts: Each object in the balances array now contains an entries array, with each entry providing an amount and description for a component of the total balance (e.g., Posted, Pending).
  • GET /subaccounts/customers/{customerId}/accounts: Same entries addition to the balances array.
Impact: This is a non-breaking change. Clients will receive additional, more detailed balance information in the API response.Example:
Deprecated

Deprecated VAULT Resource Type for Transfers and Withdrawals

Deprecated: The use of VAULT as a resource type for identifying the source and destination of funds. Users must specify a WALLET ID instead.Category: Transfers, Transactions, Vaults, WalletsEndpoints Changed:
  • POST /transactions/withdrawal: source.type/destination.type no longer accept VAULT; use WALLET.
  • POST /transfers: source.type/destination.type no longer accept VAULT; use WALLET.
  • GET /transfers: Response reflects that wallet resource type is always WALLET.
  • GET /transfers/{transferId}: Response reflects that wallet resource type is always WALLET.
  • GET /vaults: Response reflects the deprecation.
  • GET /vaults/{vaultId}: Response reflects the deprecation.
  • GET /vaults/{vaultId}/wallets: Response reflects the deprecation.
  • POST /vaults/{vaultId}/wallets: Response reflects the deprecation.
  • GET /wallets: Response reflects that wallet resource type is always WALLET.
  • GET /wallets/{walletId}: Response reflects that wallet resource type is always WALLET.
Impact: This is a breaking change. Integrations that create transfers or withdrawals by specifying a VAULT ID must be updated to use a specific WALLET ID; the previous behavior of defaulting to a vault’s default wallet is removed. This ensures all asset movements explicitly specify which wallet within a vault should be used.Example:Previous Request Structure:
New Request Structure:
Improved

Improved Trusted Destinations Response Structure

Improved: The response for listing trusted destinations now provides more detailed information — the owners array has been replaced by a structured owner object, and new name and description fields have been added.Category: Trusted DestinationsEndpoint Changed:
  • GET /trusted_destinations: owners array replaced with an owner object; added name and description fields.
Impact: This is a breaking change. Integrations that previously parsed the owners array must be updated to use the new owner object.Example:Previous Response Structure:
New Response Structure:
Improved

Improved Async Order Parameters and Content Type

Improved: Changed the request body content type and clarified the parameters property for asynchronous orders.Category: TradingEndpoint Changed:
  • POST /trading/async-order: 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, including optional endTime and required triggerPrice parameters.
Impact: This clarifies the use of the parameters property and formalizes the request body content type.
Improved

Improved Wallet Filtering Parameter Naming

Improved: Renamed the assetTypeId query parameter to assetType for wallet listing endpoints.Category: WalletsEndpoints Changed:
  • GET /vaults/{vaultId}/wallets: assetTypeId query parameter replaced with assetType.
  • GET /wallets: assetTypeId query parameter replaced with assetType.
Impact: Integrations filtering wallets by asset type must update their query parameter name from assetTypeId to assetType.
Added

Added networkId and assetTypeId Filters to Wallet Endpoints

Added networkId and assetTypeId query filters to the wallet listing endpoints.Category: WalletsEndpoints Changed:
  • GET /vaults/{vaultId}/wallets: New optional networkId and assetTypeId query parameters filter results to wallets matching the given network or asset type.
  • GET /wallets: New optional networkId and assetTypeId query parameters filter results to wallets matching the given network or asset type.
Impact: Users can now narrow down wallet listings by network or asset type without additional client-side filtering.
Added

Added Endpoint to Update Collateral Packages

Added a new endpoint to update an existing collateral package.Category: Collateral ManagementEndpoint Added:
  • PATCH /collateral_management/packages/{packageId}: Updates an existing collateral package.
Impact: Allows updating existing collateral packages.
Added

Added RFQ Order Type to Trading Endpoints

Added RFQ as a new order type on Trading endpoints.Category: TradingEndpoints Changed:
  • GET /trading/orders: orderType field in responses now includes RFQ as a possible value.
  • GET /trading/orders/{orderId}: orderType field in responses now includes RFQ as a possible value.
Impact: The list of returned orders, and any individual order retrieved, can now include orders with the RFQ type.
Added

Added Expired Status to Trusted Destinations Workflow

Added Expired as a new status value in the Trusted Destination creation request workflow.Category: Trusted DestinationsEndpoint Changed:
  • GET /trusted_destinations/{creationRequestId}/status: status field may now return Expired.
Impact: A response with status Expired indicates that the Trusted Destination creation request has expired.
Added

Added Collateral Exposures Endpoint and Updated Collateral Packages

Added support for creating collateral exposures, and updated the request body for creating collateral packages.Category: Collateral ManagementEndpoint Added:
  • POST /collateral_management/exposures: Creates a collateral exposure.
Endpoint Changed:
  • POST /collateral_management/packages: Removed the required internalName property; changed the collateralAssetsConfig array.
Impact: Users can now create collateral exposures via the API, and collateral package creation reflects the updated request body structure.
Added

Added internalName and priceStrategy to Collateral Package Creation

Added an optional internalName field and a required priceStrategy field to collateral package creation.Category: Collateral ManagementEndpoint Changed:
  • POST /collateral_management/packages: Request body now accepts an optional internalName (string) for internal tracking, and requires a priceStrategy (string) field specifying the pricing strategy, with DEFAULT as a valid enum value.
Impact: Users can now assign an internal tracking name to a collateral package and must specify a pricing strategy when creating one.
Added

Added Collateral Package Creation and Improved Package Retrieval

Added a new endpoint to create collateral packages, and expanded the response for retrieving collateral packages with more detailed level configuration.Category: Collateral ManagementEndpoint Added:
  • POST /collateral_management/packages: Creates a new collateral package.
Endpoint Changed:
  • GET /collateral_management/packages: The acceleratedMarginCall and critical objects now include returnToLtv and warningLtv properties, with the critical object now required; the action enum for these objects now includes NONE, PARTIAL, FULL, and SWEEP. The marginCall object adds curePeriod, curePeriodProtection, and topUpType properties with the same expanded action enum. The marginReturn object adds a returnToLtv property with an action enum of NONE and SWEEP.
Impact: Clients can now create collateral packages via the API and retrieve significantly more detailed information about collateral package levels and their configurations.
Added

Added GAS_STATION Transaction Type

Added GAS_STATION as a new transactionType enum value.Category: TransactionsEndpoints Changed:
  • GET /transactions: transactionType field now includes GAS_STATION.
  • GET /transactions/{transactionId}: transactionType field now includes GAS_STATION.
Impact: The transactionType field in responses can now be GAS_STATION, representing funds received from the gas station to cover network fees, providing more granular information about transaction types.
Added

Added Owners Field to Trusted Destinations Response

Added an owners field to the Trusted Destinations response.Category: Trusted DestinationsEndpoint Changed:
  • GET /trusted_destinations: Each object in the data array now includes an owners field, an array of strings representing the owners of the trusted destination.
Impact: This change provides more information about the ownership of trusted destinations.Example:
Added

Added REHYPE_IN and REHYPE_OUT Actions for Collateral Management

Added REHYPE_IN and REHYPE_OUT as new valid actions for collateral package operations, and clarified the documentation for the action property.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/operations: action field now supports REHYPE_IN and REHYPE_OUT.
  • PATCH /collateral_management/operations/{operationId}: action field now supports REHYPE_IN and REHYPE_OUT.
  • GET /collateral_management/operations: action field in responses now supports REHYPE_IN and REHYPE_OUT.
Impact: This 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. The documentation for the action property was also clarified, noting that CLOSE_RETURN is not currently supported and that write operations for liquidations are also not supported.
Improved

Improved Trusted Destination Status Granularity

Improved: Updated the possible values for the status property to provide more granularity into the Trusted Destination creation workflow.Category: Trusted DestinationsEndpoint Changed:
  • GET /trusted_destinations/{creationRequestId}/status: status field now returns one of Initiated, Generating Docusign, Pending DocuSign Signature, Trusted Destination Operation In Progress, Needs Quorum Approval, Anchorage Risk Review, Linking Trusted Destination, Complete, Failed, Rejected, or Canceled.
Impact: Users will now receive more detailed status updates during the Trusted Destination creation process — for example, Pending DocuSign Signature during the signature step, or Needs Quorum Approval while awaiting internal approvals.
Added

Added Vesting Balances Endpoint

Added a new endpoint to get vesting balances for an allocation.Category: VestingEndpoint Added:
  • GET /vesting/balances/{allocationId}: Retrieves vesting balances for a given allocation.
Impact: 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 (e.g. GET /wallets).
Added

Added Async Order Endpoint and Expanded Order Types

Added new endpoints to place and cancel asynchronous trading orders, and expanded the set of supported order types.Category: TradingEndpoints Added:
  • POST /trading/async-order: Places an async order (Market or Limit; currently only FillOrKill is supported). One of accountId or subaccountId must be specified, but not both.
  • POST /trading/async-order/cancel: Cancels an async order.
Endpoints Changed:
  • GET /trading/orders: orderType now includes STOP_LIMIT, TAKE_PROFIT_LIMIT, STOP_LOSS, TWAP, VWAP, PEGGED, POV, and OTHER; orderStatus now includes PENDING_CANCEL.
  • GET /trading/orders/{orderId}: orderType now includes STOP_LIMIT, TAKE_PROFIT_LIMIT, STOP_LOSS, TWAP, VWAP, PEGGED, POV, and OTHER.
Impact: This enables placing and canceling orders asynchronously, expands the range of order types available for trading, and the new PENDING_CANCEL status indicates that a cancellation request has been received for an async order.
Improved

Improved Webhook Endpoints with Public Key Support

Improved: Added publicKey support across webhook endpoint management, and added a new API key permission for configuring webhooks.Category: Webhook Notifications, API KeyEndpoints Changed:
  • GET /webhook/endpoints: Response now includes a publicKey property for each endpoint.
  • POST /webhook/endpoints: Request body now accepts an optional publicKey field.
  • GET /webhook/endpoints/{endpointId}: Response now includes a publicKey property.
  • PATCH /webhook/endpoints/{endpointId}: Request body now accepts a publicKey property, allowing it to be updated.
  • GET /apikey: permissions array now supports a new CONFIGURE_WEBHOOKS permission, which controls access to webhook configuration endpoints.
Impact: Clients can now set and retrieve a public key when creating or managing webhook endpoints. The new CONFIGURE_WEBHOOKS permission must be granted to an API key to create or manage webhook endpoints.
Added

Added Trusted Destinations Status Endpoint

Added a new endpoint to track the status of a Trusted Destination creation request.Category: Trusted DestinationsEndpoint Added:
  • GET /trusted_destinations/{creationRequestId}/status: Retrieves the status of a Trusted Destination creation request, using the creationRequestId path parameter (the idempotent ID provided in the Create Trusted Destination request).
Impact: Allows users to track the progress of Trusted Destination creation requests.Example:
Added

Added Create Allocations Endpoint for Wealth Management

Added the ability to create new allocations between subaccounts of the same Program Customer.Category: SubaccountsEndpoint Added:
  • POST /subaccounts/transactions/allocations: Creates new allocations between subaccounts of the same Program Customer. This is a transactional operation — either all allocations are created successfully, or none are. A maximum of 100 allocations and 10 unique assets per request are enforced. If allocations are successfully created, any relevant pending subaccount transactions are updated to reflect them.
Impact: Enables programmatic creation of allocations between subaccounts.Example:
Improved

Improved Withdrawal Requests with Trusted Destination AML Support

Improved: The withdrawal request endpoint now references Trusted Destination AML information directly, reducing the need to resubmit duplicate AML data, and adds support for Wealth Management subaccount withdrawals.Category: TransactionsEndpoint Changed:
  • POST /transactions/withdrawal: beneficiary and destination AML fields are now fully optional (not deprecated). A new optional boolean field, useTrustedDestinationAml (default false), lets the caller indicate the system should use the associated Trusted Destination’s AML information instead of resubmitting it. A new SUBACCOUNT source type is supported, with originator information auto-populated for Wealth Management clients. For joint accounts, source.customerId is now mandatory, and the AML questionnaire’s purpose field is now required.
Impact: This is a non-breaking change — useTrustedDestinationAml defaults to false, preserving prior behavior. No action is required unless you want to use the new field, in which case update your Withdrawal payload to set useTrustedDestinationAml: true and omit redundant Beneficiary/Destination AML data. This affects Withdrawal API and Wealth Management integrations.Example:Standard custody withdrawal to a Trusted Destination (originator MY_ORGANIZATION):
Wealth Management withdrawal (sourceType = SUBACCOUNT):
Added

Added Endpoint to Create Trusted Destinations

Added the ability to create trusted destinations via the API, simplifying the process for programmatic use cases. Each request requires quorum approval.Category: Trusted DestinationsEndpoint Added:
  • POST /trusted_destinations: Creates one or more trusted destination addresses (up to 10 per request). Each destination applies to a specific asset address, or to any asset on a network when isNetworkLevel is true (e.g., ETH and USDC could both be withdrawn to an ETH address); when false, only the specified asset can be withdrawn to that address. For Wealth Management integrations, the destination can be tied to an owner representing a Wealth Management CUSTOMER.
Impact: This enables programmatic creation of trusted destinations for token vesting integrations and the Wealth Management crypto withdrawal flow. A new “Manage Trusted Destinations” permission group is required to create a Trusted Destination via API. No action is required — this is an optional flow.Example:
Added

Added Placeholder Template Entry

Added a placeholder endpoint; this changelog record was left as an incomplete template without finalized details.Category: UncategorizedImpact: No functional details were provided in the original record.
Added

Added Client Account Onboarding Endpoints and Updated KYC Requirements

Added a new suite of endpoints to create “client accounts” (e.g., Joint, Roth, Custodial) that reference existing onboarding KYC profiles, and updated the KYC application to reduce required information.Category: OnboardingEndpoints Added:
  • POST /onboarding/accounts: Creates a new client account (e.g., IRA, ROTH, JOINT, CUSTODIAL, INDIVIDUAL_TAXABLE, INSTITUTIONAL_TAXABLE), referencing one or more existing program customers, signers, beneficiaries, and fee configurations.
  • GET /onboarding/accounts/{subaccountId}: Retrieves a client account application.
  • PUT /onboarding/accounts/{subaccountId}: Updates a client account application.
  • POST /onboarding/accounts/{subaccountId}/submit: Submits a client account application for review.
Endpoint Changed:
  • POST /onboarding/customers: For individuals, physicalStateUS/physicalStateOther are now conditionally required based on physicalCountry, a new idType field (GOVERNMENT_ISSUED_ID_CARD or PASSPORT) determines required identity document uploads, and initialFundingMethod, sourceOfWealth, and initialFundingWalletGroup have been removed. For institutions, physicalStateUS/physicalStateOther are similarly conditional, new hasDbaName/dbaNames and constitutionDocument/proofOfAddress fields were added, and legalStructure, customerType, countryOfIncorporation, legalRegistAddrDifPrincPlace (and its related address fields), initialFundingWalletGroup, and sourceOfWealth have been removed.
Impact: This reduces the information required for client and account onboarding and enables programmatic creation of client accounts such as Joint, Roth, and Custodial accounts, which reference the KYC profiles of their underlying program customers. This affects Wealth Management integration partners.Example:Creating a joint account:
Added

Added Detailed Level Configuration to Collateral Packages Response

Added new properties to the collateral packages response to provide more detailed information about collateral package levels and their configurations.Category: Collateral ManagementEndpoint Changed:
  • GET /collateral_management/packages: Response now includes marginReturn, marginCall, acceleratedMarginCall, and critical objects, each containing properties such as ltv, action, returnToLtv, warningLtv, and defaultNotice.
Impact: Clients can now retrieve more detailed information about collateral packages and their configurations.
Improved

Improved transactionId Parameter for Subaccount Tax Transactions

Improved: Clarified the transactionId path parameter description for updating tax transactions.Category: TaxEndpoint Changed:
  • PATCH /tax/transaction/{transactionId}: Now requires the use of the ledger transactionId rather than the previous tax transaction id (the Taxbit unique identifier).
Impact: This is a breaking change for integrations that pass the Taxbit tax transaction id; they must be updated to use the ledger transactionId instead.
Deprecated

Deprecated participantId Parameter on Atlas Settlement Rejection

Deprecated: The participantId query parameter is no longer required, and has been removed, from the settlement rejection endpoint.Category: Atlas Settlement NetworkEndpoint Changed:
  • POST /atlas/settlements/{settlementId}/reject: The participantId query parameter has been removed.
Impact: The server now infers the participant ID performing the rejection from the provided API Key, rather than requiring it as an explicit parameter.
Added

Added InvalidPrice Reject Reason to Trading Orders

Added InvalidPrice as a new possible enum value for the rejectReason property.Category: Trading OrdersEndpoint Changed:
  • POST /trading/order: rejectReason now includes InvalidPrice, providing a more specific reason for order rejection when the provided price is invalid.
Impact: Orders can now be rejected with the InvalidPrice reason, giving clearer feedback for invalid-price rejections.
Improved

Improved Subaccount Transaction Balances Structure

Improved: The amounts field in subaccount transaction responses now includes a balances array listing supported balance types for each asset and transaction, replacing the previous hold, pending, and posted properties.Category: SubaccountsEndpoints Changed:
  • GET /subaccounts/transactions: amounts.balances array replaces hold/pending/posted properties.
  • GET /subaccounts/transactions/{transactionsIds}: amounts.balances array replaces hold/pending/posted properties.
Impact: The response structure for these endpoints is now more flexible and informative, providing a clearer breakdown of balance types.Example:
Improved

Improved Tax Forms Endpoint with Customer-Based Lookup

Improved: Updated parameters for retrieving tax forms to use a customer identifier instead of an affiliate identifier.Category: TaxEndpoint Changed:
  • GET /tax/clients/{customerId}/forms: Path changed from /tax/clients/{affiliateId}/forms; the affiliateId path parameter was removed and replaced with customerId.
Impact: This is a breaking change. Integrations must be updated to use customerId instead of affiliateId when retrieving tax forms.Example:
Deprecated

Deprecated Destination and Beneficiary AML Fields for Transfers

Deprecated: The Destination and Beneficiary fields within the transfer AML questionnaire, since Anchorage now pulls this data directly from the associated Trusted Destination.Category: TransfersEndpoint Changed:
  • POST /transfers: Within transferAmlQuestionnaire, the following Destination fields are deprecated: destinationType, institutionName, institutionCountry, selfhostedDescription. The following Beneficiary fields are deprecated: recipientType, recipientFirstName, recipientLastName, recipientFullName, recipientCountry, recipientStreetAddress, recipientCity, recipientStateProvince, recipientPostalCode.
Impact: Given this deprecation, only purpose and originator information need be sent in transferAmlQuestionnaire; Destination and Beneficiary information will now come directly from the AML answers associated with the respective trusted destination.Example:
Added

Added Asset-Specific Parameters for Transfers

Added new asset-specific parameter objects to the transfer request body for providing on-chain tags or memos required by certain networks.Category: TransfersEndpoint Changed:
  • POST /transfers: Request body now accepts assetParametersXRP (destinationTag integer, for XRP transfers), assetParametersXLM (memo string, for XLM transfers), assetParametersATOM (memo string, for ATOM transfers — now deprecated in favor of assetParametersCosmos), assetParametersCosmos (memo string, for Cosmos blockchain transfers), and assetParametersExtra (value string, for other asset transfers).
Impact: This allows you to provide the additional on-chain tags or memos required to correctly identify the recipient for XRP, XLM, ATOM, Cosmos-based, and other asset transfers.
Improved

Improved Tax Transactions with Detailed Asset Breakdown

Improved: Added receivedAsset, sentAsset, and feeAsset array properties to tax transaction responses for more detailed asset information.Category: TaxEndpoint Changed:
  • GET /tax/transactions/{subaccountId}: Response now includes receivedAsset (objects with assetType, costBasis, quantity for deposits/trades), sentAsset (similar, for withdrawals/sales), and feeAsset (transaction fee detail) arrays. The existing received, sent, and fee fields remain unchanged.
Impact: This enhances the granularity of tax transaction data returned by the API, allowing for more comprehensive reporting and analysis, without affecting existing fields.
Improved

Improved Tax Endpoint Date Formatting and Added Cost Basis Date

Improved: Standardized date-time formatting for tax transaction and cost basis fields, and added a new cost basis date field.Category: TaxEndpoints Changed:
  • GET /tax/transactions/{subaccountId}: transactionTime now uses a consistent ISO-8601 date-time format.
  • GET /tax/gains/costbasis/{subaccountId}: Added a new costBasisDate field (ISO-8601 format); saleDate now uses a consistent ISO-8601 date-time format.
Impact: Date fields across these tax endpoints are now consistently formatted, and the cost basis date is now available directly in the response.
Improved

Improved Subaccount Withdrawals with Intermediary Bank Support

Improved: Subaccount withdrawal endpoints now support additional bank information fields, including an intermediary financial institution.Category: SubaccountsEndpoints Changed:
  • POST /subaccounts/{subaccountId}/fiat/withdrawals: Request body adds financialInstitution and intermediateFinancialInstitution objects (each with nested address, name, id, and code — enum ABA, BIC, DDA); bankAccountNr and bankRoutingNr moved inside beneficiary; added accountNumber within beneficiary and country within beneficiary.address.
  • GET /subaccounts/{subaccountId}/fiat/withdrawals/{transactionId}: Response customerDetails object now reflects the updated request body fields.
Impact: This adds the ability to specify an intermediary financial institution, which allows withdrawals to international banks that require one in addition to the depositing bank. Not all international withdrawals require an intermediary institution.
Added

Added Gas Station Support for Atlas Settlements

Added the ability to use the Anchorage Digital Gas Station to cover network fees for Atlas settlements (ETH only).Category: Atlas Settlement NetworkEndpoints Changed:
  • POST /atlas/settlements/{settlementId}/accept: Request body now accepts a useGasStation boolean to have Gas Station cover fees for the acceptor.
  • POST /atlas/settlements: Request body now accepts a useGasStation boolean to have Gas Station cover fees for the proposer.
  • GET /atlas/settlements: Response data.proposerSide now includes gasStationEnabled (boolean, nullable if the caller lacks access to this information).
  • GET /atlas/settlements/{settlementId}: Response settlement.proposerSide now includes gasStationEnabled (boolean, nullable if the caller lacks access to this information).
Impact: Proposers and acceptors can now request that Gas Station cover their ETH network fees, and can see whether Gas Station is enabled for a given participant on a settlement.
Improved

Improved Subaccount Transactions with Batch Creation

Improved: The subaccount transaction endpoint now accepts an array of transactions in a single request, enabling atomic creation of multiple subaccount transactions.Category: SubaccountsEndpoint Changed:
  • POST /subaccounts/transactions: Request body now accepts a transactions array of CreateSubaccountTransaction objects (each with sourceSubaccountId, destinationSubaccountId, assetType, amount, optional transactionMemo, and idempotentId), replacing the previous top-level fields of the same names. The 200 OK response now returns a transactionIds array of {transactionId, idempotentId} objects instead of a single transactionId.
Impact: This is a breaking change. Clients must update their integration to send a transactions array rather than top-level transaction fields, and to read transactionIds from the response instead of a single transactionId. This enables atomic creation of multiple subaccount transactions in one call, reducing the number of API calls required.Example:Request:
Response:
Added

Added Tax Form Endpoints for Accounts and Subaccounts

Added new endpoints to retrieve generated tax forms for affiliates and subaccounts.Category: TaxEndpoints Added:
  • GET /tax/clients/{affiliateId}/forms: Retrieves an affiliate’s generated tax forms.
  • GET /tax/subaccounts/{subaccountId}/forms: Retrieves a subaccount’s generated tax forms.
Impact: Allows retrieval of affiliate and subaccount tax forms.
Improved

Improved Tax Transaction Cost Basis Updates with Structured Lots

Improved: The tax transaction update endpoint now accepts a structured JSON payload supporting multiple tax lots.Category: TaxEndpoint Changed:
  • PATCH /tax/transaction/{transactionId}: Request body content type changed to application/json; added optional data property containing nested assetType (string) and lots (array of objects with acquisitionDatetime, quantity, and cost).
Impact: Allows updating cost basis information for tax transactions using a structured JSON payload with support for multiple tax lots, providing a more robust and organized way to manage tax-related transaction data.Example:
Added

Added Manual Billing Charges API for Wealth Management

Added new endpoints to create and cancel manual billing charges.Category: SubaccountsEndpoints Added:
  • POST /subaccounts/billing/charges: Creates manual billing charges (request body includes idempotentId, interval, feeType, and charges).
  • DELETE /subaccounts/billing/charges/{chargeId}: Cancels a manual billing charge by its chargeId.
Impact: Enables creating and canceling manual billing charges.
Improved

Improved Deposit Attributions with Date Filtering and New Fields

Improved: Added new query parameters to filter deposit attributions by date, and new fields to the response with blockchain and asset details.Category: Deposit AttributionEndpoint Changed:
  • GET /deposit-attributions/attributions: Added attributedAtStartDateTime and attributedAtEndDateTime query parameters to filter by attribution date; response now includes blockchainTxId and assetType fields.
Impact: Users can now filter deposit attributions by attribution date, and fetch the blockchain transaction ID and asset type associated with each attribution.