Skip to main content
2026 · 2025 · 2024
Added

Added Stablecoin Reserves Endpoints

Added two new endpoints to the Stablecoins API for retrieving reserve information.Category: StablecoinsEndpoints Added:
  • GET /stablecoins/reserves: Retrieves the history of stablecoin reserves.
  • GET /stablecoins/reserves/entitled-stablecoins: Gets a list of stablecoins for which the organization is entitled to view reserves.
Impact: These new endpoints allow users to programmatically access stablecoin reserve data and history.
Improved

Improved Response Structure for the List Tags Endpoint Beta

Improved The response body for the GET /tags endpoint now nests the list of tags within a data object for consistency with other API endpoints.Category: TaggingEndpoint Changed:
  • GET /tags: Returns the list of tags nested under a data object instead of at the top level.
Impact: This is a breaking change. Integrations must be updated to read the list of tags from response.data.tags instead of the top-level response.tags.Example:Previous Response Structure:
New Response Structure:
Improved

Improved Field Naming for Creating Wallets on Compatible Networks

Improved The createOnAllCompatibleNetworks field for creating wallets has been renamed to activateAllCompatibleNetworks.Category: WalletsEndpoint Changed:
  • POST /vaults/{vaultId}/wallets: The createOnAllCompatibleNetworks boolean property was removed and replaced by activateAllCompatibleNetworks.
Impact: This is a breaking change. Integrations using createOnAllCompatibleNetworks must switch to activateAllCompatibleNetworks to avoid request failures. The field’s behavior is unchanged: when set to true, it activates the new wallet on every network that is key-compatible with the primary networkId and enabled for your organization.
Improved

Improved Wallet Creation and Activation Across Compatible Networks

Improved wallet creation and activation to support all compatible networks with a single flag.Category: WalletsEndpoints Changed:
  • POST /vaults/{vaultId}/wallets: Accepts a new optional boolean parameter, createOnAllCompatibleNetworks.
  • POST /wallets/{walletId}/activate: Accepts a new optional boolean parameter, activateAllCompatibleNetworks.
Impact: This provides a more efficient way to manage wallets across multiple networks. Instead of listing every compatible network ID, you can use a single boolean flag to create or activate a wallet on all available compatible networks for your organization. The new ...AllCompatibleNetworks parameters are mutually exclusive with the existing compatibleNetworkIds parameter, so you must provide exactly one of them.
Added

Added Endpoints for Tag Management

Added a new Tags API to create, list, and manage tags for entities.Category: TagsEndpoints Added:
  • GET /tags: Lists tags.
  • POST /tags: Creates a tag.
  • POST /tags/apply: Applies tags to an entity.
  • DELETE /tags/apply/{entityId}/{tagName}: Removes a tag from an entity.
  • GET /tags/search: Searches for entities by tag.
Impact: This introduces a new feature for users to programmatically organize, categorize, and search for their resources using tags.
Improved

Improved Asset Type Details with Compatible Network IDs

Improved The GET /asset-types endpoint response now includes a list of compatible network IDs.Category: Asset TypesEndpoint Changed:
  • GET /asset-types: The AssetTypeDetails object now contains compatibleNetworkIds, an array of network IDs that share wallet key derivation with the asset’s primary network.
Impact: This helps you identify which networks can be used when creating a new wallet or activating an existing wallet on additional networks.Example:
Added

Added Tax Lot Selection for Async Orders

Added the ability to specify a tax lot ID for async sell orders for tax reporting.Category: TradingEndpoints Changed:
  • POST /trading/async-order: Accepts a new optional specLotId field to specify a tax lot to retire for SELL orders with a timeInForce of FOK; the rejectReason field in the response now includes InvalidSideForSpecLotID and InvalidTimeInForceForSpecLotID.
  • POST /trading/async-order/cancel: The rejectReason field in the response now includes InvalidSideForSpecLotID and InvalidTimeInForceForSpecLotID.
Impact: You can now programmatically manage tax lot retirement for specific SELL orders, enhancing tax reporting capabilities.
Improved

Improved Collateral Package Endpoint with Value and Price Details

Improved The response for the collateral packages endpoint now includes additional value and pricing details for each package and its underlying assets.Category: Collateral ManagementEndpoint Changed:
  • GET /collateral_management/packages: The response now includes optional exposureValue and packageValue fields at the top level of each package, plus price, quantity, and weightedValue for each asset in the collateralAssets array.
Impact: This is a non-breaking change that gives you a more complete financial overview of each collateral package directly in the list view.Example:
Added

Added Endpoint to Request Collateral Decrease

Added a new endpoint that lets users request a collateral decrease for a specified collateral package.Category: Collateral ManagementEndpoint Added:
  • POST /collateral_management/packages/{packageId}/collateral-decrease: Initiates a two-way Atlas settlement to return assets from the secured party’s collateral wallets to the pledgor’s return wallets.
Impact: This lets either the pledgor or the secured party programmatically initiate the return of collateral assets. A successful call creates an Atlas settlement, and the settlementId is returned in the response for tracking.Example:
Added

Added Endpoint to Activate Wallets on Additional Networks

Added a new endpoint to activate an existing wallet on additional compatible networks.Category: WalletsEndpoint Added:
  • POST /wallets/{walletId}/activate: Activates an existing wallet on additional compatible networks.
Impact: This lets you enable a single wallet for use across multiple networks that share the same key family, streamlining asset management without needing to create separate wallets.
Added

Added Fiat Details to Transaction Responses

Added A new fiatDetails object is now included in transaction responses to provide banking details for fiat transactions.Category: TransactionsEndpoints Changed:
  • GET /transactions: The response now includes a fiatDetails object for fiat-related transactions.
  • GET /transactions/{transactionId}: The response now includes a fiatDetails object for fiat-related transactions.
Impact: This provides key banking information, such as account number, bank name, and FedWire number, which aids in reconciliation and tracking.Example:
Added

Added Endpoint to List All Subaccounts

Added a new endpoint to retrieve all subaccounts associated with an organization.Category: SubaccountsEndpoint Added:
  • GET /subaccounts/customers/accounts: Lists all subaccounts for your organization, with filtering by subaccountIds, externalIds, endDate, and statuses, plus pagination via afterId and limit.
Impact: This provides a comprehensive, organization-level view of all subaccounts, enabling more efficient and complete data retrieval than fetching subaccounts on a per-customer basis.
Improved

Improved Transfers and Withdrawals with Trusted Destination Support

Improved Transfers and withdrawals can now use a Trusted Destination as the destination, and wallet responses can reflect it as a resource type.Category: Transfers, Transactions, WalletsEndpoints Changed:
  • POST /transactions/withdrawal: Accepts TRUSTED_DESTINATION as a destination.type value.
  • POST /transfers: Accepts TRUSTED_DESTINATION as a destination.type value.
  • GET /transfers: Can return TRUSTED_DESTINATION as a destination type in the response.
  • GET /transfers/{transferId}: Can return TRUSTED_DESTINATION as a destination type in the response.
  • GET /vaults/{vaultId}/wallets: Can return TRUSTED_DESTINATION as a wallet resource type.
  • POST /vaults/{vaultId}/wallets: Can return TRUSTED_DESTINATION as a wallet resource type.
  • GET /wallets: Can return TRUSTED_DESTINATION as a wallet resource type.
  • GET /wallets/{walletId}: Can return TRUSTED_DESTINATION as a wallet resource type.
Impact: This simplifies withdrawal and transfer workflows. You can send funds to a pre-configured Trusted Destination by providing its ID, without needing to re-specify address details, memos, or destination tags in each API call. Using Trusted Destinations also reduces the risk of sending funds to an incorrect address.Example:
Removed

Removed Wallet Activation Endpoint

Removed The endpoint for activating an existing wallet on additional compatible networks has been removed.Category: WalletsEndpoint Removed:
  • POST /wallets/{walletId}/activate
Impact: You can no longer programmatically activate an existing wallet on additional compatible networks.
Added

Added Endpoint to Activate Wallets on Additional Networks

Added a new endpoint to activate an existing wallet on additional compatible networks.Category: WalletsEndpoint Added:
  • POST /wallets/{walletId}/activate: Activates an existing wallet on additional compatible networks that share the same key family, without creating a new wallet.
Impact: This lets you enable a single wallet for use across multiple networks that share the same key family, streamlining asset management by reusing a single wallet instead of creating a new one for each network.
Added

Added Endpoint for Collateral Decrease Requests

Added a new endpoint that lets users request a collateral decrease.Category: Collateral ManagementEndpoint Added:
  • POST /collateral_management/packages/{packageId}/collateral-decrease: Enables programmatic requests to decrease collateral for a specified package.
Impact: This lets you programmatically initiate a decrease in collateral for a specific package.
Added

Added Compatible Networks Support to Wallet Creation

Added an optional compatibleNetworkIds field for activating a new wallet on additional compatible networks at the time of creation.Category: WalletsEndpoint Changed:
  • POST /vaults/{vaultId}/wallets: Accepts a new optional compatibleNetworkIds field (an array of strings).
Impact: This lets you create a wallet and activate it on multiple compatible networks in a single API call. All specified networks must share the same key family as the primary networkId, and activation happens synchronously after wallet creation.Example:
Improved

Improved Memo Handling for Fiat Trusted Destinations

Improved The behavior of the memo field for fiat transfers and withdrawals to Trusted Destinations has been clarified.Category: Transactions, Transfers, and Trusted DestinationsEndpoints Changed:
  • POST /transactions/withdrawal: The memo field within assetParametersFiatTrustedDestination is now optional; if omitted, the default memo from the saved Trusted Destination is used.
  • POST /transfers: The memo field within assetParametersFiatTrustedDestination is now optional; if omitted, the default memo from the saved Trusted Destination is used.
  • GET /trusted_destinations: The response now specifies that the memo for a fiat destination has a maximum length of 140 characters.
Impact: This simplifies API calls by letting you rely on the pre-configured memo on a Trusted Destination, reducing the need to specify it in every withdrawal or transfer request.
Improved

Improved Stablecoin History Response Field Naming

Improved In the response for the stablecoin history endpoint, the issueRedeemId field has been renamed to id.Category: StablecoinsEndpoint Changed:
  • GET /stablecoins/history: The unique identifier for an issue or redeem operation is now returned as id instead of issueRedeemId.
Impact: This is a breaking change. Integrations that parse issueRedeemId must switch to the new id field.Example:Before:
After:
Improved

Improved Stablecoin History Endpoint Pagination and Status Detail

Improved The stablecoin history response now aligns with the standard paginated format and includes more detailed status information.Category: StablecoinsEndpoint Changed:
  • GET /stablecoins/history: The response now returns a data array plus a page object for pagination (replacing hasNextPage), adds destinationOperationId and sourceOperationId, adds a status field (INITIATED, EXECUTING, COMPLETED, FAILED, UNKNOWN), adds an optional subStatus field, and expands operationType to include BRIDGE and SWAP.
Impact: This is a breaking change. The conversions array is now nested under data, and pagination uses a page.next URL instead of the previous hasNextPage boolean. Integrations must be updated to parse the new response structure.Example:
Improved

Improved Order Type Support with LIMIT_ALL_IN

Improved Added LIMIT_ALL_IN as a new possible enum value for the orderType field in trading order responses.Category: TradingEndpoints Changed:
  • GET /trading/orders: The orderType field in the response may now include LIMIT_ALL_IN.
  • GET /trading/orders/{orderId}: The orderType field in the response may now include LIMIT_ALL_IN.
Impact: Responses from the list orders and get order by ID endpoints may now include LIMIT_ALL_IN as an orderType. Make sure your client can handle this new value.
Improved

Improved Statements with Correction Timestamps and Filtering

Improved Added filtering and timestamp information for corrected statements, so you can track and query statements updated after their initial generation.Category: StatementsEndpoints Changed:
  • GET /statements: Accepts two new optional query parameters, correctedAfter and correctedBefore, to filter for statements corrected at or after or before a given time.
  • GET /statements/{statementId}: The response now includes a correctedAt field indicating when a correction was made.
Impact: You can now programmatically identify and filter for statements that have been corrected, improving audit and reconciliation workflows.Example:
Added

Added Subaccount ID Filter for Deposit Attributions

Added You can now filter deposit attributions by one or more subaccountIds.Category: Deposit AttributionEndpoint Changed:
  • GET /deposit-attributions/attributions: Accepts a new query parameter, subaccountIds.
Impact: This allows for more granular filtering of deposit attributions, making it easier to retrieve records associated with specific subaccounts.Example: GET /v2/deposit-attributions/attributions?subaccountIds=subaccount_id_1,subaccount_id_2
Improved

Improved Permission Requirements for Stablecoin History

Improved permission requirements for the stablecoin history endpoint.Category: StablecoinsEndpoint Changed:
  • GET /stablecoins/history: Now uses the more specific Read Stablecoin Conversions permission as the primary requirement.
Impact: For backward compatibility, the endpoint continues to accept the older Read vault activity permission too, so no immediate changes are required for existing integrations.
Added

Added Stablecoin Conversion History Endpoint

Added a new endpoint to retrieve the history of stablecoin issuance and redemption operations.Category: StablecoinsEndpoint Added:
  • GET /stablecoins/history: Returns a historical list of your stablecoin issuance and redemption operations.
Impact: You can now programmatically access your stablecoin conversion history for tracking and reporting purposes.
Added

Added Binance as a Price Source for Collateral Management

Added support for BINANCE as a price source in Collateral Management.Category: Collateral ManagementEndpoints Changed:
  • GET /collateral_management/price_sources: Now returns BINANCE as an available source and accepts it as a filter in the exchange query parameter.
  • POST /collateral_management/packages: The priceSource field now accepts BINANCE.
  • PATCH /collateral_management/packages/{packageId}: The priceSource field now accepts BINANCE.
  • POST /collateral_management/exposures: The priceSource field now accepts BINANCE.
Impact: This allows for more flexible pricing options when creating and managing collateral packages and exposures.Example:
Added

Added Accelerated Margin Call for Collateral Management

Added A new acceleratedMarginCall configuration level for collateral packages, letting you set an additional margin call threshold with its own LTV, cure period, and action.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: Accepts a new acceleratedMarginCall object in the request body.
  • PATCH /collateral_management/packages/{packageId}: Accepts a new acceleratedMarginCall object in the request body.
  • GET /collateral_management/packages: The response now includes the acceleratedMarginCall object.
Impact: You can now define and monitor an additional, accelerated margin call level for your collateral packages, providing more granular risk management.
Removed

Removed TRUSTED_DESTINATION Resource Type from Transfers and Wallets

Removed The TRUSTED_DESTINATION enum value from the destination.type field for transfer and withdrawal requests, and from the type field in several Wallet and Transfer responses.Category: Transfers, Transactions, and WalletsEndpoints Changed:
  • POST /transactions/withdrawal: destination.type no longer accepts TRUSTED_DESTINATION; the assetParametersATOM field is now deprecated in favor of assetParametersCosmos.
  • POST /transfers: destination.type no longer accepts TRUSTED_DESTINATION; the assetParametersATOM field is now deprecated in favor of assetParametersCosmos.
  • GET /transfers: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /transfers/{transferId}: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /vaults/{vaultId}/wallets: The type field in responses no longer returns TRUSTED_DESTINATION.
  • POST /vaults/{vaultId}/wallets: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /wallets: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /wallets/{walletId}: The type field in responses no longer returns TRUSTED_DESTINATION.
Impact: This is a breaking change. Requests that specify destination.type as TRUSTED_DESTINATION will now fail. To send funds to a trusted destination, use destination.type: 'ADDRESS' with the specific blockchain address, and update any logic that parses the type field in Wallet and Transfer responses. Users are encouraged to migrate from the deprecated assetParametersATOM to assetParametersCosmos.
Improved

Improved Order Filtering Parameter Description

Improved the description for the orderTypes query parameter to enhance clarity.Category: TradingEndpoint Changed:
  • GET /trading/orders: The description for the orderTypes parameter was updated.
Impact: This is a non-breaking documentation change. No integration updates are required.
Improved

Improved Statement Filtering and Response Structure

Improved the Statements endpoints with updated filtering parameters and a restructured response body.Category: StatementsEndpoints Changed:
  • GET /statements: Removed the statementIds, statementTypes, accountIds, affiliateIds, vaultGroupIds, and subaccountIds filter parameters, and added ids, typeIds, and customerIds. The response no longer includes accountId, affiliateId, subaccountId, vaultGroupId, or the required type field, and now includes customerId and the new required typeId field (type is now optional).
  • GET /statements/{statementId}: The response no longer includes accountId, affiliateId, subaccountId, vaultGroupId, or the required type field, and now includes customerId and the new required typeId field (type is now optional).
Impact: This is a breaking change. Integrations using the /statements endpoints must be updated to use the new query parameters and handle the modified response structure.
Improved

Improved Order Type Support with MANUAL

Improved Added support for a new MANUAL order type.Category: TradingEndpoints Changed:
  • GET /trading/orders: The orderType field in the response can now include MANUAL.
  • GET /trading/orders/{orderId}: The orderType field in the response can now include MANUAL.
Impact: Clients should update their integrations to handle this new enum value when listing or retrieving orders.
Improved

Improved Fiat Trusted Destination Response Structure

Improved The structure of the fiat object in the trusted destinations response has been refactored for clarity, with beneficiary and financial institution details now grouped into nested beneficiary and beneficiaryBank objects, plus new intermediaryBank and usage fields.Category: Trusted DestinationsEndpoint Changed:
  • GET /trusted_destinations: The fiat object’s flat beneficiary and institution properties are now nested under beneficiary and beneficiaryBank, and the object gains intermediaryBank and usage fields.
Impact: This is a breaking change. Integrations that parsed the flat properties within the fiat object must be updated to handle the new nested structure. The new usage field indicates whether the recipient account is owned by your organization or a third party.Example:Before:
After:
Added

Added Fiat Support for Trusted Destinations

Added support for fiat (bank account) trusted destinations.Category: Trusted DestinationsEndpoint Changed:
  • GET /trusted_destinations: The response now includes details for fiat-based trusted destinations.
Impact: When listing trusted destinations, a fiat destination now has a type of fiat and contains a new fiat object with detailed bank account information.Example:
Improved

Improved Order Allocation Details with Filled Quantity

Improved The allocation object in trading order responses now includes the cumQty field, which specifies the filled quantity for each subaccount allocation.Category: TradingEndpoints Changed:
  • POST /trading/order: The allocation object in the response now includes the required cumQty field.
  • GET /trading/orders: The allocation object in the response now includes the required cumQty field.
  • GET /trading/orders/{orderId}: The allocation object in the response now includes the required cumQty field.
  • POST /trading/async-order: The allocation object in the response now includes the required cumQty field.
  • POST /trading/async-order/cancel: The allocation object in the response now includes the required cumQty field.
Impact: This is a non-breaking change that provides more granular data on order fills at the subaccount level.Example:
Improved

Improved Collateral Management Price Sources Endpoint

Improved Added a new 501 Not Implemented response and clarified the exchange query parameter description.Category: Collateral ManagementEndpoint Changed:
  • GET /collateral_management/price_sources: Now returns a 501 Not Implemented error if the price sources feature is disabled; the exchange parameter description was simplified.
Impact: API consumers will now receive a 501 Not Implemented error if the price sources feature is disabled.
Improved

Improved Clarity for Tax Reporting Deposit Transaction Endpoints

Improved descriptions for the Tax Reporting endpoints to clarify that cost basis management applies specifically to deposit transactions.Category: Tax ReportingEndpoints Changed:
  • PATCH /tax/accounts/{accountId}/transactions/{transactionId}: The endpoint and hasCostBasis parameter descriptions were improved for accuracy.
  • GET /tax/accounts/{accountId}/transactions: The endpoint and hasCostBasis parameter descriptions were improved for accuracy.
Impact: This is a documentation-only change to improve clarity. The functionality of the endpoints remains unchanged.
Improved

Improved Async Order Responses with Counter Currency Details

Improved Added counterCurrency, counterQty, and counterQtyAllIn fields to the responses for placing and canceling async orders.Category: TradingEndpoints Changed:
  • POST /trading/async-order: The response now includes counterCurrency, counterQty, and counterQtyAllIn.
  • POST /trading/async-order/cancel: The response now includes counterCurrency, counterQty, and counterQtyAllIn.
Impact: The responses for placing and canceling an async order now include the counter currency, the filled quantity of the counter currency, and the filled quantity including all fees.Example:
Added

Added Collateral Management Price Sources Endpoint

Added a new endpoint to get available price sources and their supported assets.Category: Collateral ManagementEndpoint Added:
  • GET /collateral_management/price_sources: Returns supported price sources and the specific assets available for each source.
Impact: This lets clients programmatically retrieve supported price sources, which can be used to validate configurations for collateral packages.
Improved

Improved Price Strategy Options for Collateral Management

Improved The priceStrategy options for creating and managing collateral packages and exposures now include MID and LAST; VWAP has been removed.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: The priceStrategy field now accepts MID and LAST; VWAP is no longer supported.
  • PATCH /collateral_management/packages/{packageId}: The priceStrategy field now accepts MID and LAST; VWAP is no longer supported.
  • POST /collateral_management/exposures: The priceStrategy field now accepts MID and LAST; VWAP is no longer supported.
Impact: This is a breaking change. Integrations using the priceStrategy field must switch from VWAP to MID or LAST.
Added

Added Fiat Parameters for Trusted Destination Transfers and Withdrawals

Added A new assetParametersFiatTrustedDestination object to the request body for fiat transfers and withdrawals to Trusted Destinations.Category: Transactions, TransfersEndpoints Changed:
  • POST /transactions/withdrawal: Accepts a new optional assetParametersFiatTrustedDestination object with memo and purpose fields.
  • POST /transfers: Accepts a new optional assetParametersFiatTrustedDestination object with memo and purpose fields.
Impact: This lets you provide additional context when sending fiat assets to a Trusted Destination, which is useful for record-keeping and compliance.Example:
Improved

Improved Offchain Vesting Schedule Response with Asset Type

Improved the response for listing offchain vesting schedules to include the asset type.Category: VestingEndpoint Changed:
  • GET /offchainvesting/schedules: Each schedule object in the data array now includes the assetType field, specifying the asset abbreviation (for example, BTC or ETH).
Impact: This is a non-breaking, additive change that makes it easier to identify the asset associated with each vesting schedule directly from the list endpoint.
Improved

Improved Transfers and Withdrawals with Trusted Destinations

Improved You can now use pre-configured Trusted Destinations when creating transfers and withdrawals, sending funds to a TRUSTED_DESTINATION ID instead of a full address.Category: Transfers & WithdrawalsEndpoints Changed:
  • POST /transfers: The destination.type field now accepts TRUSTED_DESTINATION.
  • POST /transactions/withdrawal: The destination.type field now accepts TRUSTED_DESTINATION.
  • GET /transfers: The response can now reflect TRUSTED_DESTINATION as a destination type.
  • GET /transfers/{transferId}: The response can now reflect TRUSTED_DESTINATION as a destination type.
Impact: When sending to a TRUSTED_DESTINATION, you no longer need to include asset-specific parameters like assetParametersXRP or assetParametersXLM — the destination tag or memo is inherited automatically from the trusted destination’s configuration.Example:
Improved

Improved Market Data Endpoint with Amount-Based Depth

Improved The market data endpoint now supports returning market depth by notional value, such as USD, in addition to asset size.Category: TradingEndpoint Changed:
  • GET /trading/marketdata: A new amount field has been added to the bids and offers objects, returned when using the amountBuckets query parameter; the existing size field is returned when using sizeBuckets.
Impact: This is a non-breaking change that lets you request market depth in notional terms instead of, or alongside, asset size.Example:
Added

Added Endpoint to Propose Trusted Counterparties

Added A new endpoint to propose a new trusted counterparty.Category: Atlas Settlement NetworkEndpoint Added:
  • POST /atlas/directory/counterparties: Proposes a new trusted counterparty.
Impact: You can now programmatically propose new trusted counterparties, streamlining the process of adding new settlement partners.
Improved

Improved Market Data Parameter Descriptions

Improved descriptions for the sizeBuckets and amountBuckets query parameters to clarify their usage and impact on the response.Category: TradingEndpoint Changed:
  • GET /trading/marketdata: sizeBuckets is clarified as a comma-separated list; amountBuckets is clarified as a comma-separated list of USD values, with a note that using it affects how size is represented in the response.
Impact: This is a non-breaking documentation change that provides better guidance for querying market depth.
Improved

Improved Cost Basis Reporting with Tax Lots

Improved the Tax Reporting endpoints to support lot-level cost basis management for more granular and accurate tax data.Category: Tax ReportingEndpoints Changed:
  • PATCH /tax/accounts/{accountId}/transactions/{transactionId}: The request body now requires a lots array (each with lotId, quantity, and costBasis) in place of the previous data, acquisitionDatetime, and assetType fields.
  • GET /tax/accounts/{accountId}/transactions: The response now includes a required top-level assetType field per transaction, and an acquisitionDatetime field on each lot in the receivedAssets array.
Impact: This moves cost basis reporting from a per-transaction model to a per-lot model, letting you specify and retrieve cost basis information for individual lots within a single transaction.
Added

Added Market Data Endpoint

Added a new endpoint to retrieve a snapshot of market data.Category: TradingEndpoint Added:
  • GET /trading/marketdata: Returns a snapshot of current market data.
Impact: You can now programmatically access market data for pricing, analysis, and other trading-related activities. See the Market Data Guide for more information.
Improved

Improved Transaction Types and Settlement Parameter Documentation

Improved Added the FIAT_INTEREST transaction type and clarified the applyPostLock parameter description.Category: Transactions, Atlas Settlement NetworkEndpoints Changed:
  • GET /transactions: The transactionType field in the response can now include FIAT_INTEREST, representing fiat interest payments.
  • GET /transactions/{transactionId}: The transactionType field in the response can now include FIAT_INTEREST, representing fiat interest payments.
  • POST /atlas/settlements: The description for the applyPostLock parameter now clarifies it applies only to clients using Atlas settlements integrated with Anchorage Vesting.
Impact: Clients should update their systems to handle the new FIAT_INTEREST transaction type. The applyPostLock documentation change is non-breaking and only clarifies existing behavior.
Deprecated

Deprecated totalDistribution Field in Tax Tagging

Deprecated the totalDistribution field for tagging tax transactions.Category: TaxEndpoint Changed:
  • POST /tax/transaction/{transactionId}/tag: The totalDistribution field in the request body is now deprecated and ignored if provided.
Impact: Any value passed in totalDistribution is disregarded — total distribution status is now calculated automatically from account balances. Remove this field from your requests, since it no longer has any effect.
Added

Added Post-Settlement Locking for Atlas Settlements

Added a new applyPostLock parameter to automatically create post-settlement holds on funds received through the Atlas Settlement Network.Category: Atlas Settlement NetworkEndpoint Changed:
  • POST /atlas/settlements: Accepts a new optional boolean applyPostLock parameter; when true, indefinite holds are placed on the acceptor’s destination wallets after a successful settlement.
Impact: This enables the automatic creation of post-settlement vesting schedules on received funds, streamlining workflows that require funds to be locked after settlement.
Added

Added Vesting Schedules Endpoint and Tax Transaction Cost Basis Filter

Added a new endpoint for listing offchain vesting schedules and a new filter for tax transactions.Category: Vesting, Tax ReportingEndpoints Changed:
  • GET /offchainvesting/schedules: New endpoint that lists all offchain vesting schedules for your organization.
  • GET /tax/accounts/{accountId}/transactions: Accepts a new hasCostBasis query parameter to filter transactions that do or don’t have a cost basis.
Impact: This provides programmatic access to vesting schedules and lets you filter tax transactions by whether they have a cost basis, improving transparency and reporting.
Improved

Improved Transaction Types with Priority Fee Reward

Improved The transactionType field in transaction-related endpoints now includes PRIORITY_FEE_REWARD to represent priority fee rewards.Category: TransactionsEndpoints Changed:
  • GET /transactions: The transactionType field in the response can now include PRIORITY_FEE_REWARD.
  • GET /transactions/{transactionId}: The transactionType field in the response can now include PRIORITY_FEE_REWARD.
Impact: This new type identifies priority fee rewards, such as those from Jito priority fee distributions on Solana.
Improved

Improved Clarity for Trusted Destination Asset Type

Improved The description for the assetType field has been updated to provide better clarity when creating a trusted destination.Category: Trusted DestinationsEndpoint Changed:
  • POST /trusted_destinations: The description for assetType in the trustedDestinations array now clarifies what an asset type is and points to GET /asset-types for a list of supported types.
Impact: This is a non-breaking documentation change. The endpoint’s functionality remains the same.
Improved

Improved Security with Signature Requirements for Collateral Management

Improved security by requiring Api-Signature and Api-Timestamp headers for write operations on Collateral Management endpoints.Category: Collateral ManagementEndpoints Changed:
  • PATCH /collateral_management/operations/{operationId}: Now requires Api-Signature and Api-Timestamp headers.
  • PATCH /collateral_management/packages/{packageId}: Now requires Api-Signature and Api-Timestamp headers.
  • POST /collateral_management/exposures: Now requires Api-Signature and Api-Timestamp headers.
  • POST /collateral_management/operations: Now requires Api-Signature and Api-Timestamp headers.
  • POST /collateral_management/packages: Now requires Api-Signature and Api-Timestamp headers.
Impact: This is a breaking change. Requests to these endpoints will now fail if they don’t include valid signature and timestamp headers. See the Request Signatures section of the documentation for instructions on generating a valid signature.
Improved

Improved Wallet Responses with Unvested and Unstakeable Balances

Improved Wallet-related endpoints now include more detailed balance information for offchain vesting.Category: WalletsEndpoints Changed:
  • GET /vaults/{vaultId}/wallets: The assets object now includes unvestedBalance and unvestedUnstakeableBalance fields.
  • POST /vaults/{vaultId}/wallets: The assets object now includes unvestedBalance and unvestedUnstakeableBalance fields.
  • GET /wallets: The assets object now includes unvestedBalance and unvestedUnstakeableBalance fields.
  • GET /wallets/{walletId}: The assets object now includes unvestedBalance and unvestedUnstakeableBalance fields.
Impact: This is a non-breaking change. Responses now contain additional balance details for assets in offchain vesting contracts, where applicable.
Improved

Improved Vesting Balance Retrieval for Multiple Allocations

Improved vesting balance retrieval by adding a new endpoint to fetch balances for multiple allocations in a single request.Category: VestingEndpoint Added:
  • POST /vesting/balances: Retrieves vesting balances for multiple allocations in a single request.
Impact: This allows for more efficient retrieval of balance data by fetching information for multiple allocations at once, reducing the number of required API calls.
Improved

Improved Security with Request Signing for Atlas Settlement Endpoints

Improved security by adding request signing to key Atlas Settlement Network endpoints, which now require Api-Signature and Api-Timestamp headers.Category: Atlas Settlement NetworkEndpoints Changed:
  • POST /atlas/settlements: Now requires Api-Signature and Api-Timestamp headers.
  • POST /atlas/settlements/{settlementId}/accept: Now requires Api-Signature and Api-Timestamp headers.
  • POST /atlas/settlements/{settlementId}/authorize: Now requires Api-Signature and Api-Timestamp headers.
  • POST /atlas/settlements/{settlementId}/reject: Now requires Api-Signature and Api-Timestamp headers.
Impact: This is a breaking change. Requests made to the listed endpoints will now fail if they don’t include the required signature headers. See the Request Signatures section of the documentation for instructions on generating the required signatures.
Improved

Improved Stablecoin Conversion Documentation

Improved the description for the sourceAssetType field in the stablecoin conversion request body for clarity.Category: StablecoinsEndpoint Changed:
  • POST /stablecoins/conversion: The sourceAssetType description now clarifies that it must be USD for an issuance, and the asset being redeemed for a redemption.
Impact: This is a non-breaking documentation change.
Improved

Improved Staking Request Descriptions

Improved The descriptions for the parameters object and the stakingProviderAddress field for Solana staking requests have been updated for clarity.Category: TransactionsEndpoint Changed:
  • POST /transactions/stake: The description for the parameters object was updated, and within SOLStakingParameters, stakingProviderAddress now describes “the validator’s vote account address” instead of “the validator’s staking address”.
Impact: This is a non-breaking documentation change to provide better clarity for clients creating Solana (SOL) staking requests.
Added

Added Endpoint for Consolidating Stakes

Added a new endpoint to create a consolidate stake request.Category: TransactionsEndpoint Added:
  • POST /transactions/consolidate-stake: Initiates a request to consolidate staking positions.
Impact: This feature enhances staking management by allowing users to consolidate stakes directly through the API. See the staking guide for instructions on use.
Improved

Improved Backward Compatibility by Re-introducing the VAULT Resource Type

Improved backward compatibility by re-introducing the VAULT enum value for source and destination resources; it’s accepted but deprecated in favor of WALLET.Category: Transfers, Wallets, and TransactionsEndpoints Changed:
  • POST /transactions/withdrawal: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • POST /transfers: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • GET /transfers: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • GET /transfers/{transferId}: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • GET /vaults/{vaultId}/wallets: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • POST /vaults/{vaultId}/wallets: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • GET /wallets: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
  • GET /wallets/{walletId}: Accepts VAULT again as a resource type, though deprecated in favor of WALLET.
Impact: This restores backward compatibility for integrations still using the VAULT resource type. We strongly recommend updating existing code to use WALLET instead, since support for VAULT will be removed in a future release.
Fixed

Fixed AML Questionnaire Requirement by Organization Type

Fixed The trustedDestinationAmlQuestionnaire field is now conditionally required based on the organization type.Category: Trusted DestinationsEndpoint Changed:
  • POST /trusted_destinations: The trustedDestinationAmlQuestionnaire field is now required for Anchorage Digital organizations and must be omitted for Porto organizations.
Impact: Requests to create a trusted destination will now fail if trustedDestinationAmlQuestionnaire is included for a Porto organization or omitted for an Anchorage Digital organization.
Added

Added Endpoints for Tax Account Management

Added new endpoints to the Tax API for managing tax accounts and their associated transactions.Category: TaxEndpoints Added:
  • GET /tax/accounts: Lists tax accounts.
  • GET /tax/accounts/{accountId}/transactions: Retrieves transactions for a specific tax account.
  • PATCH /tax/accounts/{accountId}/transactions/{transactionId}: Updates the cost basis of a transaction for tax reporting.
Impact: These new endpoints let you list tax accounts, retrieve transactions for a specific account, and update the cost basis of a transaction for tax reporting purposes.
Removed

Removed TRUSTED_DESTINATION as a Resource Type

Removed The TRUSTED_DESTINATION value as a valid enum for the resource type field.Category: Transfers, Withdrawals, WalletsEndpoints Changed:
  • POST /transactions/withdrawal: The destination.type field no longer accepts TRUSTED_DESTINATION.
  • POST /transfers: The destination.type field no longer accepts TRUSTED_DESTINATION.
  • GET /transfers: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /transfers/{transferId}: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /vaults/{vaultId}/wallets: The type field in responses no longer returns TRUSTED_DESTINATION.
  • POST /vaults/{vaultId}/wallets: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /wallets: The type field in responses no longer returns TRUSTED_DESTINATION.
  • GET /wallets/{walletId}: The type field in responses no longer returns TRUSTED_DESTINATION.
Impact: This is a breaking change. API calls using destination.type: TRUSTED_DESTINATION will now fail. Specify the underlying ADDRESS or WALLET directly when creating transfers or withdrawals.
Improved

Improved Tax Transaction Tagging with IRS Combination Codes

Improved The distributionCode field for tagging tax transactions now supports IRS combination codes.Category: TaxEndpoint Changed:
  • POST /tax/transaction/{transactionId}/tag: The distributionCode field now accepts combination codes (for example, 1B, 4G, 7B) as valid enum values.
Impact: This allows for more accurate tax reporting when a distribution has multiple applicable IRS classifications, such as using 4G for a death-related direct rollover.
Improved

Improved Collateral Management Operations with Liquidation Details

Improved The response for Collateral Management Operations now includes liquidation details and an update timestamp.Category: Collateral ManagementEndpoints Changed:
  • PATCH /collateral_management/operations/{operationId}: The CMOperation model now includes updatedAt, liquidationCollateralPackageId, liquidationProceedAsset, and liquidationProceedQuantity.
  • GET /collateral_management/operations: The CMOperation model now includes updatedAt, liquidationCollateralPackageId, liquidationProceedAsset, and liquidationProceedQuantity.
Impact: This provides more comprehensive data on operations, particularly those involving liquidations.
Improved

Improved API Key Info Response with WRITE_TAX Permission

Improved Added the new WRITE_TAX permission type, which now appears in the response for the get API key info endpoint.Category: API KeyEndpoint Changed:
  • GET /apikey: The permissions array in the response now includes WRITE_TAX for API keys that have this permission.
Impact: This is a non-breaking change.Example:
Added

Added AML Questionnaire to Trusted Destination Creation

Added an optional trustedDestinationAmlQuestionnaire object to the request body for creating trusted destinations, so Anti-Money Laundering information can be submitted upfront.Category: Trusted DestinationsEndpoint Changed:
  • POST /trusted_destinations: Accepts an optional trustedDestinationAmlQuestionnaire object within each item of the trustedDestinations array.
Impact: This is a non-breaking change. Providing AML information when creating a trusted destination can streamline the approval process for future withdrawals to that address.Example:
Improved

Improved Deposit Address Security with V2 Signatures

Improved security by introducing a V2 signature scheme for deposit addresses.Category: Addresses, WalletsEndpoints Changed:
  • GET /vaults/{vaultId}/addresses: Signed address responses can now include signatureVersion and certChain fields.
  • POST /wallets/{walletId}/addresses: Signed address responses can now include signatureVersion and certChain fields.
  • GET /vaults/{vaultId}/wallets: Signed address responses can now include signatureVersion and certChain fields.
  • POST /vaults/{vaultId}/wallets: Signed address responses can now include signatureVersion and certChain fields.
  • GET /wallets: Signed address responses can now include signatureVersion and certChain fields.
  • GET /wallets/{walletId}: Signed address responses can now include signatureVersion and certChain fields.
Impact: This is a backward-compatible change that gives clients a more robust, certificate-based way to verify deposit address authenticity. When signatureVersion is V2, the certChain field contains an x509 certificate chain for verification against a trusted Anchorage Digital Root CA; if certChain is absent, use the existing V1 signature verification method. See the Address Verification guide for instructions.
Added

Added MINT Transaction Type

Added MINT as a new transaction type to represent assets minted or created on the blockchain.Category: TransactionsEndpoints Changed:
  • GET /transactions: The types query parameter now accepts MINT to filter transactions, and the transactionType field in the response can now return MINT.
  • GET /transactions/{transactionId}: The transactionType field in the response can now return MINT.
Impact: You can now filter for and identify MINT transactions across both the list and single-transaction endpoints.
Improved

Improved Error Handling for Collateral Package Updates

Improved error handling by adding a new 422 Unprocessable Entity error response to the update collateral package endpoint.Category: Collateral ManagementEndpoint Changed:
  • PATCH /collateral_management/packages/{packageId}: Now returns 422 Unprocessable Entity for requests that are syntactically correct but semantically invalid.
Impact: This lets clients differentiate between a bad request (400), a resource not found (404), and an unprocessable entity (422).
Improved

Improved Pricing Options for Collateral Management

Improved Added new options for price strategy and price source to provide more flexibility in Collateral Management configurations.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: The priceStrategy field now accepts VWAP, and the priceSource field now accepts KAMINO.
  • PATCH /collateral_management/packages/{packageId}: The priceStrategy field now accepts VWAP, and the priceSource field now accepts KAMINO.
  • POST /collateral_management/exposures: The priceStrategy field now accepts VWAP, and the priceSource field now accepts KAMINO.
Impact: You can now specify VWAP (Volume-Weighted Average Price) as a pricing strategy and KAMINO as a price source when creating or updating collateral packages and exposures.
Added

Added BURN Transaction Type

Added a new BURN transaction type to represent assets that are burned or destroyed on the blockchain.Category: TransactionsEndpoints Changed:
  • GET /transactions: The types query parameter now accepts BURN to filter transactions, and the transactionType field in the response can now return BURN.
  • GET /transactions/{transactionId}: The transactionType field in the response can now return BURN.
Impact: This helps with clearer categorization of on-chain asset destruction events.
Removed

Removed priceSourceProvider from Collateral Management Endpoints

Removed the priceSourceProvider field from the request bodies of several Collateral Management endpoints.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: The priceSourceProvider field is no longer available in collateralAssetsConfig.
  • PATCH /collateral_management/packages/{packageId}: The priceSourceProvider field is no longer available in collateralAssetsConfig.
  • POST /collateral_management/exposures: The priceSourceProvider field is no longer available in assetTrackingConfig.
Impact: API requests that include the priceSourceProvider field will now result in an error. Update your integrations to remove this field to ensure successful requests.
Improved

Improved Collateral Management Operations with GAS_FEE Action

Improved the CMOperation model to include a new GAS_FEE action type.Category: Collateral ManagementEndpoints Changed:
  • PATCH /collateral_management/operations/{operationId}: The action field in the response can now include GAS_FEE.
  • GET /collateral_management/operations: The action field in the response can now include GAS_FEE.
Impact: This provides more granular detail on operation types.
Improved

Improved Fiat Deposit Instructions with Memo Field

Improved A memoField has been added to the depositInstruction object returned for fiat wallets.Category: WalletsEndpoints Changed:
  • GET /vaults/{vaultId}/wallets: The depositInstruction object for fiat wallets now includes memoField.
  • POST /vaults/{vaultId}/wallets: The depositInstruction object for fiat wallets now includes memoField.
  • GET /wallets: The depositInstruction object for fiat wallets now includes memoField.
  • GET /wallets/{walletId}: The depositInstruction object for fiat wallets now includes memoField.
Impact: This is a non-breaking, additive change. Include this memo on wire deposits to ensure funds are attributed correctly to the wallet.Example:
Improved

Improved Wallet Details with Fiat Deposit Instructions

Improved Wallet-related endpoints now include a depositInstruction object with banking details for fiat wallets, distinct from crypto wallet addresses.Category: WalletsEndpoints Changed:
  • GET /vaults/{vaultId}/wallets: The response now conditionally includes the depositInstruction object for fiat wallets.
  • POST /vaults/{vaultId}/wallets: The response now conditionally includes the depositInstruction object for fiat wallets.
  • GET /wallets: The response now conditionally includes the depositInstruction object for fiat wallets.
  • GET /wallets/{walletId}: The response now conditionally includes the depositInstruction object for fiat wallets.
Impact: The depositAddress object remains for crypto wallets. The description for the assets array has also been clarified to state that it may be empty.Example:
Improved

Improved Collateral Management Package Updates and API Refinements

Improved the Collateral Management API for more comprehensive control and clarity, including support for partial updates to a package’s entire configuration.Category: Collateral ManagementEndpoints Changed:
  • PATCH /collateral_management/packages/{packageId}: You can now update nearly all configuration details of a package, including clientReferenceId, collateralAssetsConfig, ltvRoundingPrecision, priceStrategy, and settings for critical, marginCall, marginReturn, and autoDeleveraging levels; omitted fields remain unchanged.
  • PATCH /collateral_management/operations/{operationId}: The type field no longer accepts the LIQUIDATION enum value, and the typeId description was improved for clarity.
  • POST /collateral_management/operations: The type field no longer accepts the LIQUIDATION enum value, and the typeId description was improved for clarity.
  • GET /collateral_management/exposures: Field descriptions were updated for accuracy and clarity.
  • POST /collateral_management/packages: Field descriptions were updated for accuracy and clarity.
  • GET /collateral_management/packages: Field descriptions were updated for accuracy and clarity.
Impact: These changes provide significantly more flexibility for programmatically managing collateral packages and improve the overall clarity and usability of the Collateral Management API.
Added

Added Collateral Management Operation Actions

Added new action types for creating and updating Collateral Management operations.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/operations: The action field now supports CLOSE_RETURN, REHYPE_IN, and REHYPE_OUT.
  • PATCH /collateral_management/operations/{operationId}: The action field now supports CLOSE_RETURN, REHYPE_IN, and REHYPE_OUT.
Impact: You can now create and update operations to manage the closing of returns and rehypothecation for collateral packages.
Added

Added Fields for Tax Transaction Tagging

Added new conditional fields for tagging tax transactions to support more detailed reporting.Category: TaxEndpoint Changed:
  • POST /tax/transaction/{transactionId}/tag: The request body now supports distributionCode (required when tag is distribution), totalDistribution (required when tag is distribution), and postponedLateReason (required when tag is postponed or late-rollover).
Impact: When tagging transactions with distribution, postponed, or late-rollover, you must now provide these additional details for more accurate tax reporting.Example:
Improved

Improved Collateral Management API Clarity and Field Support

Improved several Collateral Management endpoints for clarity and functionality, with updated field descriptions and examples throughout.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: Removed the defaultGroupId parameter from the request body.
  • GET /collateral_management/packages: Removed acceleratedMarginCall from the response, and added CURE_PERIOD_EXPIRED and DEFAULTED to the state enum.
  • POST /collateral_management/exposures: Descriptions improved for clarity.
  • GET /collateral_management/exposures: Descriptions improved for clarity.
  • POST /collateral_management/operations: Removed several unsupported enum values from the action field to reflect currently available actions.
  • GET /collateral_management/operations: Descriptions improved for clarity.
  • PATCH /collateral_management/operations/{operationId}: Removed several unsupported enum values from the action field to reflect currently available actions.
Impact: Descriptions were improved across all listed endpoints for parameters such as clientReferenceId, pledgorId, curePeriod, ltv, and topUpType, giving clearer guidance when configuring collateral packages, exposures, and operations.
Improved

Improved Price Strategy Options with BID and ASK

Improved Added BID and ASK as valid options for the priceStrategy field when creating collateral packages and exposures.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: The priceStrategy field now accepts BID and ASK.
  • POST /collateral_management/exposures: The priceStrategy field now accepts BID and ASK.
Impact: This provides more granular control over pricing strategy, letting you specify whether the bid or ask price should be used when creating new collateral packages and exposures.
Improved

Improved Filtering for List Orders Endpoint

Improved order filtering capabilities by adding a new orderTypes parameter.Category: TradingEndpoint Changed:
  • GET /trading/orders: Accepts a new optional orderTypes query parameter, an array of strings to filter by order type (LIMIT, MARKET, STOP_LOSS, STOP_LIMIT, TAKE_PROFIT_LIMIT, TWAP, VWAP, PEGGED, POV, OTHER).
Impact: This allows for more granular querying of orders, letting you retrieve only the specific order types you’re interested in.Example: GET /v2/trading/orders?orderTypes=LIMIT,STOP_LIMIT
Improved

Improved Customer Onboarding with Single-Call Submission

Improved the customer onboarding workflow by adding an optional submit parameter.Category: OnboardingEndpoint Changed:
  • POST /onboarding/customers: Accepts a new optional boolean submit parameter.
Impact: This is a non-breaking change. When submit is true, the application is created and submitted in a single call, eliminating the need for a separate submission request and reducing the number of required API calls.
Improved

Improved Price Source Options with KRAKEN

Improved Added KRAKEN as a supported price source for collateral management.Category: Collateral ManagementEndpoints Changed:
  • POST /collateral_management/packages: The priceSource field now accepts KRAKEN.
  • POST /collateral_management/exposures: The priceSource field now accepts KRAKEN.
Impact: This provides more flexibility by letting you select Kraken as the data source for asset pricing when configuring collateral.