Added Stablecoin Reserves Endpoints
- Added two new endpoints to the Stablecoins API for retrieving reserve information.
- Category: Stablecoins
- Endpoints 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.
Updated Response Structure for List Tags Endpoint
- Improved: The response body for the
GET /tagsendpoint has been updated to nest thetagsarray within adataobject for consistency with other API endpoints.- Category: Tagging
-
Endpoint Changed:
GET /tags -
Impact: This is a structural change. Integrations that consume this endpoint must be updated to access the list of tags from
response.data.tagsinstead of the top-levelresponse.tags. -
Example:
Previous Response Structure:
New Response Structure:
Improved Response Structure for Listing Tags
- Improved: The response body for the
GET /tagsendpoint has been updated to nest the results within adataobject for improved consistency with other API endpoints.- Category: Tagging
- Endpoint Changed:
GET /tags - Impact: This is a breaking change. You will need to update your integration to access the array of tags from
response.data.tagsinstead of directly fromresponse.tags. - Example:
- Old Response:
- New Response:
- Old Response:
Standardized Response Structure for the List Tags Endpoint
- Improved
- Description: The response body for the
GET /tagsendpoint has been updated to a standardized format. The list of tags is now nested under a newdataobject. - Category: Tagging
- Endpoint Changed:
GET /tags - Impact: This is a structural change that requires clients to update their response parsing logic. The array of tags is no longer at the root level of the response.
- Example:
Before:
After:
- Additional Information: This change aligns the
GET /tagsendpoint with the standard data object wrapper used across the API, improving consistency.
- Description: The response body for the
Standardized Response for List Tags Endpoint
- Improved
- Description: The response for
GET /tagshas been updated to nest the tag list within adataobject for standardization. - Category: Tagging
- Endpoint Changed:
listTags - Method:
GET - Path:
/tags - Impact: This is a breaking change. Integrations must be updated to parse the new response structure. The array of tags, previously at the root level, is now located inside the
dataobject. - Example:
- Old Response Structure:
- New Response Structure:
- Old Response Structure:
- Description: The response for
Updated Response Structure for List Tags Endpoint
- Improved: The response structure for the
GET /tagsendpoint has been updated to improve consistency across the API.- Category: Tagging
- Endpoints Changed:
GET /tags
- Impact: This is a breaking change. The
tagsarray is no longer at the root level of the response. Integrations parsing this endpoint must be updated to access the list of tags from the newdata.tagspath. - Example:
- Old Response:
- New Response:
- Old Response:
Standardized Response Structure for the List Tags Endpoint
- Improved
- Description: The response body for the
GET /tagsendpoint has been updated. The array of tags, previously at the top level of the response, is now nested within adataobject. - Category: Tagging
- Endpoint Changed:
GET /tags - Impact: This is a breaking change. You will need to update your integration to access the list of tags from
response.data.tagsinstead of the previousresponse.tags. - Example:
Before:
After:
- Additional Information: This change aligns the response structure with our other paginated endpoints for better consistency across the API.
- Description: The response body for the
Standardized Response for List Tags Endpoint
- Improved: The response structure for the
GET /tagsendpoint has been updated to standardize its structure. The list of tags is now nested within adataobject.- Category: Tagging
- Endpoint Changed:
GET /tags - Impact: This is a breaking change. Integrations will need to be updated to access the array of tags from the
data.tagsfield instead of the top-leveltagsfield. - Example:
- Before:
- After:
- Before:
- Additional Information: This change aligns the response format with other list endpoints across the API for better consistency.
Updated Response Structure for List Tags Endpoint
- Improved
- The response body for the
GET /tagsendpoint has been restructured for consistency. Thetagsarray is now nested within adataobject. - Category: Tagging
- Endpoint Changed:
GET /tags - Impact: This is a breaking change. Integrations that parse the response from this endpoint must be updated to access the list of tags from the
data.tagsfield instead of the previous top-leveltagsfield. - Example:
- Previous Response:
- New Response:
- Previous Response:
- The response body for the
Updated Response Structure for List Tags Endpoint
- Improved
- Description: The response structure for the
GET /tagsendpoint has been updated. The list of tags is now nested within adataobject to align with the standard API response format. - Category: Tagging
- Endpoint:
GET /tags - Impact: This is a structural change. Client integrations must be updated to access the list of tags from the
data.tagsfield instead of the previous top-leveltagsfield. - Example:
Previous Response Structure:
New Response Structure:
- Description: The response structure for the
Renamed Field for Creating Wallets on Compatible Networks
- Improved: The
createOnAllCompatibleNetworksfield has been renamed toactivateAllCompatibleNetworks.- Category: Wallets
- Endpoint Changed:
POST /vaults/{vaultId}/wallets
- Request Body: The
createOnAllCompatibleNetworksboolean property was removed and replaced byactivateAllCompatibleNetworks. - Impact: This is a breaking change. Integrations using the
createOnAllCompatibleNetworksfield must be updated to use the newactivateAllCompatibleNetworksfield to avoid request failures. - Additional Information: The functionality of the field remains the same: when set to
true, it activates the new wallet on every network that is key-compatible with the primarynetworkIdand enabled for your organization.
Streamlined Wallet Creation and Activation Across Compatible Networks
- Improved wallet creation and activation to support all compatible networks with a single flag.
- Category: Wallets
- Endpoints Changed:
POST /vaults/{vaultId}/walletsPOST /wallets/{walletId}/activate
- Request Body:
- The
POST /vaults/{vaultId}/walletsendpoint now includes a new optional boolean parameter,createOnAllCompatibleNetworks. - The
POST /wallets/{walletId}/activateendpoint now includes a new optional boolean parameter,activateAllCompatibleNetworks.
- The
- Impact: These changes provide a more efficient way to manage wallets across multiple networks. Instead of listing every compatible network ID, you can now use a single boolean flag to create or activate a wallet on all available compatible networks for your organization.
- Additional Information: The new
...AllCompatibleNetworksparameters are mutually exclusive with the existingcompatibleNetworkIdsparameter. You must provide exactly one of these parameters in your request.
Added New Endpoints for Tag Management
- Added a new “Tags” API to create, list, and manage tags for entities.
- Type: Added
- Category: Tags
- Endpoints Added:
GET /tagsto list tags.POST /tagsto create a tag.POST /tags/applyto apply tags to an entity.DELETE /tags/apply/{entityId}/{tagName}to remove a tag from an entity.GET /tags/searchto search for entities by tag.
- Impact: This introduces a new feature for users to programmatically organize, categorize, and search for their resources using tags.
Enhanced Asset Type Information with Compatible Networks
- Improved: The
GET /asset-typesendpoint response now includes a list of compatible network IDs.- Category: Asset Types
- Endpoint Changed:
GET /asset-types - Impact: The
AssetTypeDetailsobject in the response now containscompatibleNetworkIds, an array of network IDs that share wallet key derivation with the asset’s primary network. This helps you identify which networks can be used when creating a new wallet or activating an existing wallet on additional networks. - Example:
Added Specific Lot ID for Tax Reporting in Async Orders
- Added the ability to specify a tax lot ID for async sell orders for tax reporting.
- Category: Trading
- Endpoints Changed:
POST /trading/async-orderPOST /trading/async-order/cancel
- Changes:
- Added: A new optional
specLotIdfield has been introduced in the request body for thePOST /trading/async-orderendpoint. This allows you to specify a tax lot to retire forSELLorders with atimeInForceofFOK. - Improved: The
rejectReasonfield in the responses for bothPOST /trading/async-orderandPOST /trading/async-order/cancelnow includes two new enum values to provide more specific error feedback:InvalidSideForSpecLotIDandInvalidTimeInForceForSpecLotID.
- Added: A new optional
- Impact: You can now programmatically manage tax lot retirement for specific
SELLorders, enhancing tax reporting capabilities.
Enhanced Collateral Package Endpoint with Value and Price Details
- Improved
- Description: The response for the
GET /collateral_management/packagesendpoint has been enhanced to include additional value and pricing details for each collateral package and its underlying assets. - Category: Collateral Management
- Endpoint Changed:
GET /collateral_management/packages
- Impact: This is a non-breaking change. The
200 OKresponse now includes the following new optional fields:exposureValueandpackageValueat the top level of each package object.price,quantity, andweightedValuefor each asset within thecollateralAssetsarray. These additions provide a more comprehensive financial overview of each collateral package directly in the list view.
- Example:
- Description: The response for the
Added New Endpoint to Request Collateral Decrease
- Added a new endpoint that allows users to request a collateral decrease for a specified collateral package. This initiates a two-way Atlas settlement to return assets from the secured party’s collateral wallets to the pledgor’s return wallets.
- Category: Collateral Management
- Endpoint Changed:
POST /collateral_management/packages/{packageId}/collateral-decrease - Impact: This new functionality enables either the pledgor or the secured party to programmatically initiate the return of collateral assets. The successful API call creates an Atlas settlement, and the
settlementIdis returned in the response for tracking. - Example Request Body:
Added Wallet Activation on Additional Networks
- Added
- Added a new endpoint to activate an existing wallet on additional compatible networks.
- Category: Wallets
- Endpoint Changed:
POST /wallets/{walletId}/activate - Impact: This allows users to 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 Fiat Details to Transaction Responses
- Added: A new
fiatDetailsobject is now included in transaction responses to provide banking details for fiat transactions.- Category: Transactions
- Endpoints Changed:
GET /transactionsGET /transactions/{transactionId}
- Impact: When fetching a list of transactions or a single transaction, the response will now contain a
fiatDetailsobject for any fiat-related transactions. This provides key banking information such as account number, bank name, and FedWire number, which aids in reconciliation and tracking. - Example:
Added Endpoint to List All Subaccounts
- Added a new endpoint to retrieve all subaccounts associated with an organization.
- Category: Subaccounts
- Endpoint:
GET /subaccounts/customers/accounts - Description: This endpoint allows users to list all subaccounts for their organization, with options for filtering and pagination.
- Parameters:
subaccountIds(query): Filter results by a list of subaccount IDs.externalIds(query): Filter results by a list of IDs from an external system.endDate(query): Filter for subaccounts created up to and including the specified date.statuses(query): Filter subaccounts by their status.afterId(query): Paginate to the next page of results.limit(query): Specify the maximum number of results to return.
- Impact: This new endpoint provides a comprehensive, organization-level view of all subaccounts, enabling more efficient and complete data retrieval compared to fetching subaccounts on a per-customer basis.
Enhanced Transfers and Withdrawals with Trusted Destinations
- Improved: Added the ability to use
TRUSTED_DESTINATIONas a destination type for transfers and withdrawals, streamlining the process for sending assets to pre-approved addresses.- Category: Transfers, Transactions, Wallets
- Endpoints Changed:
POST /transactions/withdrawalPOST /transfersGET /transfersGET /transfers/{transferId}GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Request Body:
- The
destination.typefield in the request body forPOST /transfersandPOST /transactions/withdrawalnow acceptsTRUSTED_DESTINATIONas a valid enum value. - Descriptions for asset-specific parameters (e.g.,
assetParametersXRP,assetParametersCosmos) have been updated to clarify that they should not be provided when sending to aTRUSTED_DESTINATION, as the relevant information (like memo or destination tag) is inherited from the trusted destination’s configuration.
- The
- Responses:
- The
destination.typefield in responses forGET /transfersandGET /transfers/{transferId}can now returnTRUSTED_DESTINATION. - The
typefield in wallet-related responses (GET /wallets,GET /vaults/{vaultId}/wallets, etc.) can now also includeTRUSTED_DESTINATION.
- The
- Impact: This change simplifies withdrawal and transfer workflows. Users can now send funds to a pre-configured Trusted Destination by simply providing its ID, without needing to re-specify address details, memos, or destination tags in each API call.
- Example: To withdraw funds to a trusted destination, you can now structure your request body as follows:
- Additional Information: Using Trusted Destinations reduces the risk of sending funds to an incorrect address and streamlines recurring transactions.
Enhanced Transfers and Withdrawals with Trusted Destination Support
- Improved
- You can now send funds to pre-approved Trusted Destinations when creating transfers and withdrawals. This simplifies the process by allowing you to use a
TRUSTED_DESTINATIONas thedestination.typein your request. When a Trusted Destination is used, asset-specific parameters like memos or destination tags are automatically inherited from its configuration and should no longer be provided in the API call. - Category: Transfers & Transactions
- Endpoints Changed:
POST /transfersPOST /transactions/withdrawalGET /transfersGET /transfers/{transferId}
- Impact:
- The
destination.typefield in the request body for creating transfers and withdrawals now acceptsTRUSTED_DESTINATIONas a value. - When sending to a
TRUSTED_DESTINATION, you no longer need to include asset-specific parameter objects (e.g.,assetParametersXRP,assetParametersXLM,assetParametersCosmos). - Responses for
GET /transfersandGET /transfers/{transferId}will now also reflect when aTRUSTED_DESTINATIONwas used as the destination.
- The
- Example: To create a withdrawal to a Trusted Destination, set the
destinationobject in the request body like this:
- You can now send funds to pre-approved Trusted Destinations when creating transfers and withdrawals. This simplifies the process by allowing you to use a
Removed Wallet Activation Endpoint
- Removed: The endpoint for activating an existing wallet on additional compatible networks has been removed.
- Category: Wallets
- Endpoint Removed:
POST /wallets/{walletId}/activate - Impact: Users can no longer programmatically activate an existing wallet on additional compatible networks.
Added Endpoint to Activate Wallets on Additional Networks
- Added a new endpoint to activate an existing wallet on additional compatible networks.
- Category: Wallets
- Endpoint Added:
POST /wallets/{walletId}/activate - Impact: This allows users to programmatically activate an existing wallet on additional networks that share the same key family. This streamlines asset management across multiple networks by reusing a single wallet, rather than creating a new one for each network.
Added Endpoint to Activate Wallets on Additional Networks
- Added a new endpoint to activate an existing wallet on additional compatible networks.
- Category: Wallets
- Endpoint Changed:
POST /wallets/{walletId}/activate - Impact: This new endpoint allows users to make an existing wallet functional on other compatible networks after its initial creation. This provides more flexibility than only being able to specify compatible networks at the time of wallet creation.
Added Endpoint for Collateral Decrease Requests
- Added a new endpoint to allow users to request a collateral decrease.
- Category: Collateral Management
- Endpoint:
POST /collateral_management/packages/{packageId}/collateral-decrease - Description: This new endpoint enables programmatic requests to decrease collateral for a specified package.
Added Support for Compatible Networks on Wallet Creation
- Added an optional
compatibleNetworkIdsfield to thePOST /vaults/{vaultId}/walletsendpoint. This allows for activating a new wallet on additional compatible networks at the time of creation.- Category: Wallets
- Endpoint Changed:
POST /vaults/{vaultId}/wallets - Request Body: A new optional field
compatibleNetworkIds(an array of strings) has been added. - Impact: This change allows you to create a wallet and simultaneously activate it on multiple compatible networks in a single API call, streamlining the setup process.
- Additional Information: All specified networks must share the same key family as the primary
networkId. The activation on these compatible networks occurs synchronously after the initial wallet creation. - Example Request Body:
Clarified Memo Handling for Fiat Trusted Destinations
- Improved: The behavior of the
memofield for fiat transfers and withdrawals to Trusted Destinations has been clarified.- Category: Transactions, Transfers, and Trusted Destinations
- Endpoints Changed:
POST /transactions/withdrawalPOST /transfersGET /trusted_destinations
- Impact:
- For withdrawal and transfer requests (
POST /transactions/withdrawal,POST /transfers), thememofield withinassetParametersFiatTrustedDestinationis now optional. If it’s not provided in the request, the default memo from the saved Trusted Destination will be used. - The response for
GET /trusted_destinationsnow specifies that thememofor a fiat destination has a maximum length of 140 characters.
- For withdrawal and transfer requests (
- Additional Information: This enhancement simplifies API calls by allowing you to rely on the pre-configured memo on a Trusted Destination, reducing the need to specify it in every withdrawal or transfer request.
Updated Stablecoin History Response Field
- Improved
-
Description: In the response for
GET /stablecoins/history, theissueRedeemIdfield has been renamed toid. - Category: Stablecoins
-
Endpoint Changed:
GET /stablecoins/history -
Impact: This is a breaking change. Integrations that parse the
issueRedeemIdfield must be updated to use the newidfield to get the unique identifier for an issue/redeem operation. -
Example:
Before:
After:
-
Description: In the response for
Standardized and Enhanced Stablecoin History Endpoint Response
- Improved The response for the Stablecoin History endpoint has been updated to align with our standard paginated format and now includes more detailed status information.
- Category: Stablecoins
- Endpoint Changed:
GET /stablecoins/history - Impact: This is a breaking change. The response body has been restructured. The
conversionsarray is now nested under adatafield, and pagination is handled by apageobject with anextURL, replacing the previoushasNextPageboolean. - Changes:
- The response now returns a
dataarray containing the list of conversions and apageobject for pagination. - Added
destinationOperationIdandsourceOperationIdto link to the corresponding transaction details. - Added a
statusfield with possible values:INITIATED,EXECUTING,COMPLETED,FAILED,UNKNOWN. - Added an optional
subStatusfield to provide more context on thestatus, such asREJECTED_BY_CUSTOMER. - The
operationTypeenum is expanded to includeBRIDGEandSWAP.
- The response now returns a
- Example (New Response Structure):
- Additional Information: Integrations using this endpoint must be updated to parse the new response structure.
Added LIMIT_ALL_IN Order Type to Trading Endpoints
- Improved
- Description: Added
LIMIT_ALL_INas a new possible enum value for theorderTypefield in trading order responses. - Category: Trading
- Endpoints Changed:
GET /trading/ordersGET /trading/orders/{orderId}
- Impact: Responses from the “List orders” and “Get order by ID” endpoints may now include
LIMIT_ALL_INas anorderType. Ensure your client can handle this new value.
- Description: Added
Enhanced Statements with Correction Timestamps and Filtering
- Improved
- Added filtering and timestamp information for corrected statements. This allows for better tracking and querying of statements that have been updated after their initial generation.
- Category: Statements
- Endpoints Changed:
GET /statementsGET /statements/{statementId}
- Parameters:
- For
GET /statements, two new optional query parameters have been added:correctedAfter: Filters for statements corrected at or after this time.correctedBefore: Filters for statements corrected at or before this time.
- For
- Impact: Users can now programmatically identify and filter for statements that have been corrected, improving audit and reconciliation workflows. The
correctedAtfield in the response indicates precisely when a correction was made. - Example: A response for a corrected statement will now include the
correctedAtfield.
Added Subaccount ID Filter for Deposit Attributions
- Added: You can now filter deposit attributions by one or more
subaccountIds.- Category: Deposit Attribution
- Endpoint Changed:
GET /deposit-attributions/attributions - Parameter: A new query parameter,
subaccountIds, has been added. - 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
Updated Permissions for Stablecoin History Endpoint
- Improved permission requirements for the Stablecoin History endpoint.
- Category: Stablecoins
- Endpoint Changed:
GET /stablecoins/history - Impact: The primary permission required for this endpoint has been updated from
Read vault activityto the more specificRead Stablecoin Conversions. For backward compatibility, the endpoint will continue to accept theRead vault activitypermission, so no immediate changes are required for existing integrations.
Added Stablecoin Conversion History Endpoint
- Added a new endpoint to retrieve the history of stablecoin issuance and redemption operations.
- Category: Stablecoins
- Endpoint:
GET /stablecoins/history - Description: This new endpoint allows users to get a historical list of their stablecoin issuance and redemption operations.
- Impact: Clients can now programmatically access their stablecoin conversion history for tracking and reporting purposes.
Added Binance as a Price Source for Collateral Management
- Added support for
BINANCEas a price source in Collateral Management.- Category: Collateral Management
- Endpoints Changed:
GET /collateral_management/price_sourcesPOST /collateral_management/packagesPATCH /collateral_management/packages/{packageId}POST /collateral_management/exposures
- Impact: The
priceSourcefield in various Collateral Management endpoints now acceptsBINANCEas a valid enum value. This allows for more flexible pricing options when creating and managing collateral packages and exposures. TheGET /collateral_management/price_sourcesendpoint now also returnsBINANCEas an available source and can be used as a filter in theexchangequery parameter. - Example: When creating or updating a collateral package, you can now specify Binance as the price source for an asset:
Added Accelerated Margin Call for Collateral Management
- Added: A new
acceleratedMarginCallconfiguration level has been introduced for collateral packages. This allows for setting up an additional margin call threshold with a specific LTV, cure period, and action.- Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/packagesPATCH /collateral_management/packages/{packageId}GET /collateral_management/packages
- Impact: Users can now define and monitor an additional, accelerated margin call level for their collateral packages, providing more granular risk management.
- Details:
- The
acceleratedMarginCallobject has been added to the request body for creating (POST) and updating (PATCH) collateral packages. - The
acceleratedMarginCallobject is now included in the response body when retrieving (GET) collateral package details.
- The
Updated Transfer and Withdrawal Destination Handling
- Removed
TRUSTED_DESTINATIONas a resource type and updated asset parameter descriptions- Type: Removed
- Description: The enum value
TRUSTED_DESTINATIONhas been removed from thedestination.typefield for transfer and withdrawal requests. This value has also been removed from thetypefield in responses for several Wallet and Transfer endpoints. Additionally, descriptions for various asset-specific parameters have been updated to clarify their usage and deprecateassetParametersATOM. - Category: Transfers, Transactions, and Wallets
- Endpoints Changed:
POST /transactions/withdrawalPOST /transfersGET /transfersGET /transfers/{transferId}GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Request Body:
- In
POST /transactions/withdrawalandPOST /transfers:- The
destination.typefield no longer acceptsTRUSTED_DESTINATION. - The
assetParametersATOMfield is now deprecated in favor ofassetParametersCosmos. - Descriptions for
assetParametersCosmos,assetParametersXLM,assetParametersXRP, andassetParametersExtrahave been updated to clarify that they are not needed when using a trusted destination.
- The
- In
- Impact: This is a breaking change. API requests that specify
destination.typeasTRUSTED_DESTINATIONwill now fail. To send funds to a trusted destination, you must now usedestination.type: 'ADDRESS'and provide the specific blockchain address associated with that trusted destination. Clients should also update any logic that parses thetypefield in Wallet and Transfer-related responses. - Additional Information: Users are encouraged to migrate from using the deprecated
assetParametersATOMto the more generalassetParametersCosmosfor Cosmos-based assets.
Improved Documentation for Order Filtering
- Improved the description for the
orderTypesquery parameter to enhance clarity.- Category: Trading
- Endpoint:
GET /trading/orders - Parameters: The description for the
orderTypesparameter was updated. - Impact: This is a non-breaking documentation change. No integration updates are required.
Improved Statement Filtering and Response Structure
- Improved the
Statementsendpoints with updated filtering parameters and a restructured response body.- Type: Improved
- Category: Statements
- Endpoints Changed:
GET /statementsGET /statements/{statementId}
- Impact: This is a breaking change. Integrations using the
/statementsendpoints must be updated to use the new query parameters and handle the modified response structure. - Changes:
- The
GET /statementsendpoint has new query parameters for filtering:- Removed:
statementIds,statementTypes,accountIds,affiliateIds,vaultGroupIds,subaccountIds. - Added:
ids,typeIds,customerIds.
- Removed:
- The response bodies for both
GET /statementsandGET /statements/{statementId}have been updated:- Removed Fields:
accountId,affiliateId,subaccountId,vaultGroupId, and the requiredtypefield. - Added Fields:
customerIdand the new required fieldtypeId. Thetypefield is now optional.
- Removed Fields:
- The
Added MANUAL Order Type to Trading Endpoints
- Improved: Added support for a new
MANUALorder type.- Category: Trading
- Endpoints Changed:
GET /trading/ordersGET /trading/orders/{orderId}
- Impact: The
orderTypefield in the responses for listing and retrieving orders can now include the valueMANUAL. Clients should update their integrations to handle this new enum value.
Refactored Fiat Trusted Destination Response Structure
- Improved
- Description: The structure of the
fiatobject in the response for listing trusted destinations has been refactored for clarity. Beneficiary and financial institution details are now grouped into nestedbeneficiaryandbeneficiaryBankobjects. Additionally, newintermediaryBankandusagefields have been added. - Category: Trusted Destinations
- Endpoint Changed:
GET /trusted_destinations - Impact: This is a breaking change. Integrations that previously parsed the flat properties within the
fiatobject must be updated to handle the new nested structure. - Example:
Before:
After:
- Additional Information:
- The new
usagefield indicates if the recipient account is owned by your organization or a third party. - All previous properties like
beneficiaryName,institutionName, etc., are now nested within thebeneficiaryandbeneficiaryBankobjects.
- The new
- Description: The structure of the
Added Fiat Support for Trusted Destinations
- Added support for fiat (bank account) trusted destinations
- Category: Trusted Destinations
- Endpoint Changed:
GET /trusted_destinations - Description: The
GET /trusted_destinationsendpoint response has been updated to include details for fiat-based trusted destinations. - Impact: When listing trusted destinations, the response for a fiat destination will now have a
typeoffiatand contain a newfiatobject with detailed bank account information. - Example:
Enhanced Order Allocation Details with Filled Quantity
- Improved
- Description: The
allocationobject in trading order responses now includes thecumQtyfield, which specifies the filled quantity for each subaccount allocation. - Category: Trading
- Endpoints Changed:
POST /trading/orderGET /trading/ordersGET /trading/orders/{orderId}POST /trading/async-orderPOST /trading/async-order/cancel
- Impact: This is a non-breaking change that provides more granular data on order fills at the subaccount level. The
cumQtyfield is now a required property within theallocationobject in the responses for the affected endpoints. - Example: The
allocationobject in the response will now includecumQty:
- Description: The
Updated Collateral Management Price Sources Endpoint
- Improved:
- Added a new
501 Not Implementedresponse to thegetCMPriceSourcesendpoint. - Clarified the description for the
exchangequery parameter. - Category: Collateral Management
- Endpoint Changed:
GET /collateral_management/price_sources - Impact: API consumers will now receive a
501 Not Implementederror if the price sources feature is disabled. Theexchangeparameter description has been simplified.
- Added a new
Improved Clarity for Tax Reporting Deposit Transaction Endpoints
- Improved
- Description: We’ve updated our Tax Reporting API to clarify that the endpoints for managing transaction cost basis are specific to deposit transactions. The descriptions for the endpoints and the
hasCostBasisparameter have been improved for better accuracy. - Category: Tax Reporting
- Endpoints Changed:
PATCH /tax/accounts/{accountId}/transactions/{transactionId}GET /tax/accounts/{accountId}/transactions
- Impact: This is a documentation-only change to improve clarity. The functionality of the endpoints remains unchanged.
- Description: We’ve updated our Tax Reporting API to clarify that the endpoints for managing transaction cost basis are specific to deposit transactions. The descriptions for the endpoints and the
Enhanced Async Order Responses with Counter Currency Details
- Improved
- Description: Added
counterCurrency,counterQty, andcounterQtyAllInfields to the responses for placing and canceling async orders. This provides more detailed information about the counter currency involved in the transaction. - Category: Trading
- Endpoints Changed:
POST /trading/async-orderPOST /trading/async-order/cancel
- Impact: The responses for placing and canceling an async order will now include the counter currency, the filled quantity of the counter currency, and the filled quantity including all fees.
- Example:
- Description: Added
Added Collateral Management Price Sources Endpoint
- Added a new endpoint to get available price sources and their supported assets.
- Category: Collateral Management
- Endpoint Added:
GET /collateral_management/price_sources - Impact: This allows clients to programmatically retrieve a list of supported price sources and the specific assets available for each source, which can be used to validate configurations for collateral packages.
Updated Price Strategy Options for Collateral Management
- Improved: The
priceStrategyoptions have been updated for creating and managing collateral packages and exposures. TheMIDandLASToptions have been added, andVWAPhas been removed.- Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/packagesPATCH /collateral_management/packages/{packageId}POST /collateral_management/exposures
- Request Body: The
priceStrategyfield within the request body for these endpoints now acceptsMIDandLASTas enum values. TheVWAPvalue is no longer supported. - Impact: Integrations that use the
priceStrategyfield must be updated to use the newMIDorLASTvalues instead ofVWAP.
Added Fiat Parameters for Trusted Destination Transfers and Withdrawals
- Added: A new
assetParametersFiatTrustedDestinationobject to the request body for fiat transfers and withdrawals to Trusted Destinations.- Category: Transactions, Transfers
- Endpoints Changed:
POST /transactions/withdrawalPOST /transfers
- Request Body: The request bodies for both endpoints now include the optional
assetParametersFiatTrustedDestinationobject. This object contains two new fields:memo: A note to the beneficiary.purpose: The purpose of the transaction (e.g.,TRADING_SETTLEMENT,INVESTMENT).
- Impact: This change allows you to provide additional context and details when sending fiat assets to a Trusted Destination. This is particularly useful for record-keeping and compliance.
- Example: When making a fiat withdrawal to a Trusted Destination, you can now include the purpose of the transaction.
Enhanced Offchain Vesting Schedule Information
- Improved the response for listing offchain vesting schedules
- Category: Vesting
- Endpoint Changed:
GET /offchainvesting/schedules
- Description: The response for
GET /offchainvesting/scheduleshas been updated to include theassetTypefield in each schedule object within thedataarray. This new field specifies the asset abbreviation (e.g., BTC, ETH) for the vesting schedule. - Impact: This is a non-breaking, additive change. It allows for easier identification of the asset associated with each vesting schedule directly from the list endpoint.
Improved Transfers and Withdrawals with Trusted Destinations
- Improved: You can now use pre-configured Trusted Destinations when creating transfers and withdrawals. This simplifies the process by allowing you to send funds to a
TRUSTED_DESTINATIONID instead of a full address, automatically inheriting necessary details like memos or destination tags.- Category: Transfers & Withdrawals
- Endpoints Changed:
POST /transfersPOST /transactions/withdrawalGET /transfersGET /transfers/{transferId}
- Request Body:
- For
POST /transfersandPOST /transactions/withdrawal, thedestination.typefield now acceptsTRUSTED_DESTINATION.
- For
- Impact: When initiating a transfer or withdrawal to a
TRUSTED_DESTINATION, you no longer need to include asset-specific parameters likeassetParametersXRPorassetParametersXLM. The required destination tag or memo is automatically inherited from the trusted destination’s configuration. - Example:
- Additional Information: The responses for
GET /transfersandGET /transfers/{transferId}will also now reflectTRUSTED_DESTINATIONas a possible destination type.
Enhanced Market Data Endpoint with Amount-Based Depth
- Improved
- Description: The
GET /trading/marketdataendpoint has been enhanced to support returning market depth by notional value (e.g., in terms of the quote currency like USD) in addition to asset size. - Category: Trading
- Endpoint:
GET /trading/marketdata - Impact: A new
amountfield has been added to thebidsandoffersobjects in the response. This field is returned when using theamountBucketsquery parameter and represents the notional value available at a given price level. The existingsizefield is now returned when using thesizeBucketsparameter. This is a non-breaking change. - Example:
- Description: The
Added Endpoint to Propose Trusted Counterparties
- Added: A new endpoint
POST /atlas/directory/counterpartieshas been introduced to allow for the proposal of a new trusted counterparty.- Category: Atlas Settlement Network
- Endpoint:
POST /atlas/directory/counterparties - Impact: Users can now programmatically propose new trusted counterparties, streamlining the process of adding new settlement partners.
Improved Market Data Parameter Descriptions
- Improved
- Description: The descriptions for the
sizeBucketsandamountBucketsquery parameters have been updated to provide more clarity on their usage and impact on the response. - Category: Trading
- Endpoint Changed:
GET /trading/marketdata - Parameters Changed:
sizeBuckets: Clarified that the value is a comma-separated list.amountBuckets: Clarified that the value is a comma-separated list representing USD values and added a note that using this parameter affects how thesizefield is represented in the response.
- Impact: This is a non-breaking documentation change that provides better guidance for users querying market depth.
- Description: The descriptions for the
Improved Cost Basis Reporting with Tax Lots
- Improved
- Updated the Tax Reporting endpoints to support lot-level cost basis management, providing more granular and accurate tax data.
- Category: Tax Reporting
- Endpoints Changed:
PATCH /tax/accounts/{accountId}/transactions/{transactionId}GET /tax/accounts/{accountId}/transactions
- Changes:
PATCH /tax/accounts/{accountId}/transactions/{transactionId}:- Request Body: The request body for updating a transaction’s cost basis has been updated to support multiple tax lots.
- Replaced the
data,acquisitionDatetime, andassetTypefields with a new requiredlotsarray. Each object in thelotsarray represents a tax lot and must includelotId,quantity, andcostBasis.
- Replaced the
- Request Body: The request body for updating a transaction’s cost basis has been updated to support multiple tax lots.
GET /tax/accounts/{accountId}/transactions:- Response Body: The response for listing transactions has been enhanced to include more detailed lot information.
- Added a required top-level
assetTypefield to each transaction object. - Added an
acquisitionDatetimefield to each lot object within thereceivedAssetsarray.
- Added a required top-level
- Response Body: The response for listing transactions has been enhanced to include more detailed lot information.
- Impact: These changes transition our cost basis reporting from a per-transaction model to a more detailed per-lot model. Users can now specify and retrieve cost basis information for individual lots within a single transaction, enabling more precise tax reporting.
Added Market Data Endpoint
- Added a new endpoint to retrieve a snapshot of market data.
- Category: Trading
- Endpoint:
GET /trading/marketdata - Description: This new endpoint allows users to get a snapshot of current market data.
- Impact: Users can now programmatically access market data for pricing, analysis, and other trading-related activities.
Added FIAT_INTEREST Transaction Type and Improved Settlement Documentation
- Improved: Added the
FIAT_INTERESTtransaction type and clarified theapplyPostLockparameter description.- A new
FIAT_INTERESTvalue has been added to thetransactionTypeenum to represent fiat interest payments.- Category: Transactions
- Endpoints Changed:
GET /transactionsGET /transactions/{transactionId}
- Impact: The
transactionTypefield in the response for these endpoints can now includeFIAT_INTEREST. Clients should update their systems to handle this new transaction type.
- The description for the
applyPostLockparameter has been updated for clarity.- Category: Atlas Settlement Network
- Endpoint Changed:
POST /atlas/settlements - Request Body: The description for the
applyPostLockparameter now specifies that it is a conditional field applicable only to clients using Atlas settlements integrated with Anchorage Vesting.
- A new
Deprecated totalDistribution Field in Tax Tagging
- Deprecated the
totalDistributionfield for tagging tax transactions.- Category: Tax
- Endpoint Changed:
POST /tax/transaction/{transactionId}/tag - Request Body: The
totalDistributionfield is now deprecated and will be ignored if provided. - Impact: Any value passed in the
totalDistributionfield will be disregarded. The total distribution status is now automatically calculated from account balances. - Additional Information: Users should remove the
totalDistributionfield from their requests as it no longer has any effect.
Added Post-Settlement Locking for Atlas Settlements
- Added a new
applyPostLockparameter to automatically create post-settlement holds on funds received through the Atlas Settlement Network.- Category: Atlas Settlement Network
- Endpoint Changed:
POST /atlas/settlements
- Request Body:
- A new optional boolean parameter
applyPostLockhas been added. When set totrue, indefinite holds will be placed on the acceptor’s destination wallets after a successful settlement.
- A new optional boolean parameter
- Impact: This feature enables the automatic creation of post-settlement vesting schedules on received funds, streamlining workflows that require funds to be locked after settlement.
New Vesting Schedules Endpoint and Tax Transaction Filtering
- Added a new endpoint for listing offchain vesting schedules and a new filter for tax transactions.
- Added:
- Description: A new endpoint,
GET /offchainvesting/schedules, has been introduced to allow users to list all offchain vesting schedules for their organization. - Category: Vesting
- Endpoint Changed:
GET /offchainvesting/schedules - Impact: This provides programmatic access to view vesting schedules, enhancing transparency and management of vested assets.
- Description: A new endpoint,
- Added:
- Description: The
GET /tax/accounts/{accountId}/transactionsendpoint now includes a newhasCostBasisquery parameter. - Category: Tax Reporting
- Endpoint Changed:
GET /tax/accounts/{accountId}/transactions - Parameters: Added
hasCostBasisinquery. - Impact: Users can now filter transactions to easily identify which ones have or are missing a cost basis. Set to
trueto list only transactions with a cost basis,falsefor those without, or omit the parameter to list all transactions.
- Description: The
- Added:
Added Priority Fee Reward Transaction Type
- Improved: The
transactionTypefield in transaction-related endpoints now includesPRIORITY_FEE_REWARDto represent priority fee rewards.- Category: Transactions
- Endpoints Changed:
GET /transactionsGET /transactions/{transactionId}
- Impact: When listing or retrieving individual transactions, you may now see
PRIORITY_FEE_REWARDin thetransactionTypefield of the response. This new type identifies priority fee rewards, such as those from Jito priority fee distributions on Solana.
Improved Clarity for Trusted Destination Asset Type
- Improved: The description for the
assetTypefield has been updated to provide better clarity when creating a trusted destination.- Category: Trusted Destinations
- Endpoint Changed:
POST /trusted_destinations - Request Body: The description for the
assetTypefield within thetrustedDestinationsarray now clarifies what an asset type is and directs users to the/v2/asset-typesendpoint to find a list of supported types. - Impact: This is a non-breaking documentation change. The endpoint’s functionality remains the same.
Added Signature Requirements for Collateral Management Write Operations
- Improved: To enhance security,
Api-SignatureandApi-Timestampheaders are now required for write operations on Collateral Management endpoints.- Category: Collateral Management
- Endpoints Changed:
PATCH /collateral_management/operations/{operationId}PATCH /collateral_management/packages/{packageId}POST /collateral_management/exposuresPOST /collateral_management/operationsPOST /collateral_management/packages
- Parameters Added: The
Api-SignatureandApi-Timestampheaders have been added as required parameters for the listed endpoints. - Impact: This is a breaking change. Requests to these endpoints will now fail if they do not include valid signature and timestamp headers.
- Additional Information: For instructions on how to generate a valid request signature, please see the Request Signatures section of our documentation.
Added Unvested and Unstakeable Balances to Wallet Responses
- Improved: Wallet-related endpoints now include more detailed balance information for offchain vesting.
- Category: Wallets
- Endpoints Changed:
GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Response Body Changes: The
assetsobject within the response bodies for these endpoints now includes two newAmountobject fields:unvestedBalanceandunvestedUnstakeableBalance. - Impact: This is a non-breaking change. API responses will now contain additional balance details for assets in offchain vesting contracts, where applicable.
New Vesting Endpoint
- Added
- Description: A new endpoint has been added to retrieve vesting balances for multiple allocations in a single request.
- Category: Vesting
- Endpoint Changed:
POST /vesting/balances - 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.
Added Request Signing to Atlas Settlement Endpoints
- Improved: Added request signing to enhance security for key Atlas Settlement Network endpoints. These endpoints now require an
Api-SignatureandApi-Timestampheader for all requests.- Category: Atlas Settlement Network
- Endpoints Changed:
POST /atlas/settlementsPOST /atlas/settlements/{settlementId}/acceptPOST /atlas/settlements/{settlementId}/authorizePOST /atlas/settlements/{settlementId}/reject
- Parameters added:
Api-Signature,Api-Timestamp(header). - Impact: This is a breaking change. Requests made to the listed endpoints will now fail if they do not include the required signature headers.
- Additional Information: Please refer to the Request Signatures section in the documentation for detailed instructions on generating the required signatures.
Improved Stablecoin Conversion Documentation
- Improved: Updated the description for the
sourceAssetTypefield in the stablecoin conversion request body to provide more clarity.- Category: Stablecoins
- Endpoint Changed:
POST /stablecoins/conversion - Impact: This is a non-breaking documentation change. The new description clarifies that for an issuance, the
sourceAssetTypemust beUSD, and for a redemption, it must be the asset being redeemed.
Improved Staking Request Descriptions
- Type: Improved
- Brief description of the change: The descriptions for the
parametersobject and thestakingProviderAddressfield for Solana staking requests have been updated for clarity. - Category of API endpoints that changed: Transactions
- The endpoint that changed: Create a stake request
- The method of the endpoint that changed:
POST - The path of the endpoint that changed:
/transactions/stake - The request body of the endpoint that changed:
- The description for the
parametersobject was updated. - In the
SOLStakingParametersobject, the description for thestakingProviderAddressfield was changed from “The validator’s staking address” to “The validator’s vote account address”.
- The description for the
- Impact: This is a non-breaking documentation change to provide better clarity for clients creating Solana (SOL) staking requests.
Added Endpoint for Consolidating Stakes
- Added a new endpoint to create a consolidate stake request.
- Category: Transactions
- Endpoint Added:
POST /transactions/consolidate-stake - Description: This new endpoint enables users to programmatically initiate a request to consolidate their staking positions.
- Impact: This feature enhances staking management by allowing users to consolidate stakes directly through the API.
Re-introduced VAULT Resource Type for Backward Compatibility
- Improved: The
VAULTenum value has been re-introduced to thetypefield for source and destination resources in various endpoints. WhileVAULTis now an accepted value, it is considered deprecated, and developers should useWALLETinstead.- Category: Transfers, Wallets, and Transactions
- Endpoints Changed:
POST /transactions/withdrawalPOST /transfersGET /transfersGET /transfers/{transferId}GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Impact: This change ensures backward compatibility for integrations that may still be using the
VAULTresource type. For all new and updated integrations,WALLETshould be used as the resource type. - Additional Information: We strongly recommend updating any existing code to use the
WALLETresource type to ensure future compatibility, as support for theVAULTtype will be removed in a future release.
Updated AML Requirements for Creating Trusted Destinations
- Improved The
trustedDestinationAmlQuestionnairefield is now conditionally required based on the organization type.- Category: Trusted Destinations
- Endpoint Changed:
POST /trusted_destinations - Request Body: The
trustedDestinationAmlQuestionnairefield is now required for Anchorage Digital organizations and must be omitted for Porto organizations. - Impact: API requests to create a trusted destination will fail if the
trustedDestinationAmlQuestionnaireis included for a Porto organization or omitted for an Anchorage Digital organization.
Added New Endpoints for Tax Account Management
- Added
- Description: Introduced new endpoints to the Tax API for managing tax accounts and their associated transactions.
- Category: Tax
- Endpoints Changed:
GET /tax/accountsGET /tax/accounts/{accountId}/transactionsPATCH /tax/accounts/{accountId}/transactions/{transactionId}
- Impact: These new endpoints provide functionality to list tax accounts, retrieve transactions for a specific account, and update the cost basis of a transaction for tax reporting purposes.
Removal of TRUSTED_DESTINATION as a Resource Type
- Removed: The
TRUSTED_DESTINATIONvalue has been removed as a valid enum for the resourcetypefield.- Category: Transfers, Withdrawals, Wallets
- Endpoints Changed:
POST /transactions/withdrawalPOST /transfersGET /transfersGET /transfers/{transferId}GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Impact:
- Requests: For
POST /transactions/withdrawalandPOST /transfers, thedestination.typefield in the request body no longer acceptsTRUSTED_DESTINATION. API calls using this value will now fail. - Responses: For
GET /transfers,GET /transfers/{transferId},GET /wallets,GET /wallets/{walletId},GET /vaults/{vaultId}/wallets, andPOST /vaults/{vaultId}/wallets, thetypefield within various response objects will no longer returnTRUSTED_DESTINATION.
- Requests: For
- Additional Information: This change standardizes resource types. Users should now specify the underlying
ADDRESSorWALLETdirectly when creating transfers or withdrawals.
Expanded IRS Distribution Codes for Tax Transaction Tagging
- Improved: The
distributionCodefield for tagging tax transactions now supports IRS combination codes.- Category: Tax
- Endpoint Changed:
POST /tax/transaction/{transactionId}/tag - Request Body: The
distributionCodefield within the request body for the “Add Tag to Transaction” endpoint has been updated to include combination codes as valid enum values. - Impact: This allows for more accurate tax reporting by enabling the use of combination codes (e.g.,
1B,4G,7B) for distributions that have multiple applicable IRS classifications. - Example: When tagging a distribution transaction, you can now provide a
distributionCodeof4Gto represent a death-related direct rollover.
Enhanced Collateral Management Operations with Liquidation Details
- Improved: The response for Collateral Management Operations has been enhanced to include liquidation details and an update timestamp.
- Category: Collateral Management
- Endpoints Changed:
PATCH /collateral_management/operations/{operationId}GET /collateral_management/operations
- Impact: The
CMOperationmodel returned by these endpoints now includes the following new fields, providing more comprehensive data on operations, particularly those involving liquidations:updatedAt(string): The timestamp of when the operation was last updated.liquidationCollateralPackageId(string): The unique identifier of the collateral package being liquidated.liquidationProceedAsset(object): The asset symbol or ticker for the proceeds of the liquidation.liquidationProceedQuantity(string): The decimal quantity of the proceeds received from the liquidation.
Added New WRITE_TAX Permission
- Improved
- Added the new
WRITE_TAXpermission type. This will now appear in the response for the Get API Key Info endpoint. - Category: API Key
- Endpoint Changed:
GET /apikey - Impact: The response for the
GET /apikeyendpoint will now includeWRITE_TAXin thepermissionsarray for API keys that have this permission. This is a non-breaking change. - Example:
- Added the new
Enhanced Trusted Destination Creation with AML Questionnaire
- Improved: Added an optional
trustedDestinationAmlQuestionnaireobject to the request body for creating trusted destinations. This allows for the submission of Anti-Money Laundering (AML) information upfront when creating a new destination.- Category: Trusted Destinations
- Endpoint Changed:
POST /trusted_destinations - Request Body: Each object within the
trustedDestinationsarray in the request body now accepts the optionaltrustedDestinationAmlQuestionnairefield. - Impact: This is a non-breaking change. Providing AML information during the creation of a trusted destination can help streamline the approval process for future withdrawals to that address.
Added AML Questionnaire to Trusted Destination Creation
- Added an optional
trustedDestinationAmlQuestionnaireobject to streamline the creation of trusted destinations.- Category: Trusted Destinations
- Endpoint Changed:
POST /trusted_destinations - Request Body: The request body for creating a trusted destination now accepts an optional
trustedDestinationAmlQuestionnaireobject within each item of thetrustedDestinationsarray. - Impact: This is a non-breaking change. You can now provide Anti-Money Laundering (AML) information directly when creating a new trusted destination, which can help streamline the approval process.
- Example:
Added AML Questionnaire to Trusted Destination Creation
- Added: An optional
trustedDestinationAmlQuestionnaireobject can now be included when creating a new trusted destination.- Category: Trusted Destinations
- Endpoint Changed:
POST /trusted_destinations - Request Body: The objects within the
trustedDestinationsarray now accept a new optionaltrustedDestinationAmlQuestionnairefield. - Impact: This is a non-breaking change. It allows users to provide required Anti-Money Laundering (AML) information upfront when creating a destination, which can streamline future withdrawal requests.
- Example:
Enhanced Deposit Address Security with V2 Signatures
- Improved
- Description: Introduced a V2 signature scheme for deposit addresses to provide an enhanced security model. Responses that include signed address information will now contain two new fields:
signatureVersionandcertChain. ThesignatureVersionfield indicates the signature scheme in use. WhenV2is present, thecertChainfield will contain an x509 certificate chain for verification against a trusted Anchorage Digital Root CA. - Category: Addresses, Wallets
- Endpoints Changed:
GET /vaults/{vaultId}/addressesPOST /wallets/{walletId}/addressesGET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Impact: This change provides clients with a more robust, certificate-based method for verifying the authenticity of deposit addresses. The change is backward-compatible; if the
certChainfield is absent, the existing V1 signature verification method (using the Organization Public Key) should be used. - See instructions in Address Verification guide
- Description: Introduced a V2 signature scheme for deposit addresses to provide an enhanced security model. Responses that include signed address information will now contain two new fields:
Added MINT Transaction Type
- Added
MINTas a new transaction type to represent assets minted or created on the blockchain.- Category: Transactions
- Endpoints Changed:
GET /transactionsGET /transactions/{transactionId}
- Methods: GET
- Paths:
/transactions/transactions/{transactionId}
- Parameters: The
typesquery parameter for theGET /transactionsendpoint now acceptsMINTas a value to filter transactions. - Impact: The
transactionTypefield in the responses for the transaction endpoints can now returnMINT.
New Error Response for Collateral Package Updates
- Improved
- Description: Added a new
422 Unprocessable Entityerror response to theUpdate a collateral packageendpoint. This provides more specific feedback for requests that are syntactically correct but semantically invalid and cannot be processed. - Category: Collateral Management
- Endpoint Changed:
PATCH /collateral_management/packages/{packageId}
- Impact: This enhances error handling by allowing clients to differentiate between a bad request (
400), a resource not found (404), and an unprocessable entity (422).
- Description: Added a new
New 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 Management
- Endpoints Changed:
POST /collateral_management/packagesPATCH /collateral_management/packages/{packageId}POST /collateral_management/exposures
- Request Body:
- The
priceStrategyfield now accepts the enum valueVWAP. - The
priceSourcefield now accepts the enum valueKAMINO.
- The
- Impact: Users can now specify
VWAP(Volume-Weighted Average Price) as a pricing strategy andKAMINOas a price source when creating or updating collateral packages and exposures.
Added ‘BURN’ Transaction Type
- Added a new
BURNtransaction type- Type: Added
- Description: We have introduced a new
transactionTypecalledBURNto represent assets that are burned or destroyed on the blockchain. This helps in the clearer categorization of on-chain asset destruction events. - Category: Transactions
- Endpoints Changed:
GET /transactionsGET /transactions/{transactionId}
- Impact: You can now filter for
BURNtransactions by including it in thetypesquery parameter of theGET /transactionsendpoint. TheBURNtype will also appear in thetransactionTypefield in the responses for bothGET /transactionsandGET /transactions/{transactionId}.
Removed priceSourceProvider from Collateral Management Endpoints
- Removed
- Description: Removed the
priceSourceProviderfield from the request bodies of several Collateral Management endpoints. - Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/packagesPATCH /collateral_management/packages/{packageId}POST /collateral_management/exposures
- Request Body: The
priceSourceProviderfield is no longer available in thecollateralAssetsConfigobject when creating or updating a collateral package, nor in theassetTrackingConfigobject when creating an exposure. - Impact: API requests to these endpoints that include the
priceSourceProviderfield will now result in an error. Integrations must be updated to remove this field to ensure successful requests.
- Description: Removed the
Added GAS_FEE Action for Collateral Management Operations
- Improved the
CMOperationmodel to include a newGAS_FEEaction type.- Category: Collateral Management
- Endpoints Changed:
PATCH /collateral_management/operations/{operationId}GET /collateral_management/operations
- Impact: The
actionfield in the responses for these endpoints can now include the valueGAS_FEE, providing more granular detail on operation types.
Enhanced Fiat Deposit Instructions with Memo Field
- Improved: A
memoFieldhas been added to thedepositInstructionobject, which is returned for fiat wallets in several wallet-related endpoints.- Category: Wallets
- Endpoints Changed:
GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Impact: This is a non-breaking, additive change. Responses for the affected endpoints will now include a
memoFieldwithin thedepositInstructionobject for fiat wallets. - Additional Information: This memo should be included on wire deposits to ensure funds are attributed correctly to the wallet.
- Example: The
depositInstructionobject in the response for a fiat wallet will now include the new field.
Enhanced Wallet Details with Fiat Deposit Instructions
- Improved
- Description: Wallet-related endpoints have been updated to include specific deposit instructions for fiat wallets, distinguishing them from crypto wallet addresses. The response for these endpoints now includes a new
depositInstructionobject for fiat wallets. - Category: Wallets
- Endpoints Changed:
GET /vaults/{vaultId}/walletsPOST /vaults/{vaultId}/walletsGET /walletsGET /wallets/{walletId}
- Impact: Responses for the listed endpoints will now conditionally include the
depositInstructionobject for fiat wallets, containing banking details for deposits. ThedepositAddressobject remains for crypto wallets. The description for theassetsarray has also been clarified to state that it may be empty. - Example: A fiat wallet in the response will now contain a
depositInstructionobject.
- Description: Wallet-related endpoints have been updated to include specific deposit instructions for fiat wallets, distinguishing them from crypto wallet addresses. The response for these endpoints now includes a new
Enhanced Collateral Management Package Updates and API Refinements
- Improved
- The Collateral Management API has been updated to provide more comprehensive control and clarity. The endpoint for updating a collateral package now supports partial updates to its entire configuration, and several other endpoints have been refined.
- Category: Collateral Management
- Endpoints Changed:
PATCH /collateral_management/packages/{packageId}PATCH /collateral_management/operations/{operationId}POST /collateral_management/operationsGET /collateral_management/exposuresPOST /collateral_management/packagesGET /collateral_management/packages
- Changes:
PATCH /collateral_management/packages/{packageId}: This endpoint has been significantly enhanced. You can now update nearly all configuration details of a package, includingclientReferenceId,collateralAssetsConfig,ltvRoundingPrecision,priceStrategy, and settings forcritical,marginCall,marginReturn, andautoDeleveraginglevels. Fields that are omitted in the request will remain unchanged.POST & PATCH /collateral_management/operations: Thetypefield in the request body has been refined; theLIQUIDATIONenum value has been removed to clarify the available operation types. The description fortypeIdwas also improved for clarity.- Other Endpoints: Descriptions for various fields across
GET /collateral_management/exposures,POST /collateral_management/packages, andGET /collateral_management/packageshave been updated to provide more accurate and clear documentation.
- 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 New Collateral Management Operation Actions
- Added new
actiontypes for creating and updating Collateral Management operations.- Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/operationsPATCH /collateral_management/operations/{operationId}
- Request Body: The
actionfield in the request body for both endpoints now supports the following new enum values for collateral packages:CLOSE_RETURNREHYPE_INREHYPE_OUT
- Impact: Users can now create and update operations to manage the closing of returns and rehypothecation for collateral packages.
Enhanced Tax Transaction Tagging with New Fields
- Added new conditional fields for tagging tax transactions to support more detailed reporting.
- Type: Added
- Category: Tax
- Endpoint Changed:
POST /tax/transaction/{transactionId}/tag - Request Body: The following fields have been added to the request body for the
tagTaxTransactionoperation:distributionCode(string): Now required when thetagisdistribution. This field is for the IRS distribution code for Form 1099-R.totalDistribution(boolean): Now required when thetagisdistribution. Indicates if this is a total distribution of the account.postponedLateReason(string): Now required when thetagispostponedorlate-rolloverto provide a reason.
- Impact: When tagging transactions with
distribution,postponed, orlate-rollover, users must now provide these additional details for more accurate tax reporting. - Example:
Updates to Collateral Management API
- Improved: We’ve enhanced several endpoints in the Collateral Management API to improve clarity and functionality. Descriptions for numerous fields have been updated to provide more context and examples.
- Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/packagesGET /collateral_management/packagesPOST /collateral_management/exposuresGET /collateral_management/exposuresPOST /collateral_management/operationsGET /collateral_management/operationsPATCH /collateral_management/operations/{operationId}
- Key Changes:
- For the
Create a new collateral packageendpoint (POST /collateral_management/packages), thedefaultGroupIdparameter has been removed from the request body. - For the
List packagesendpoint (GET /collateral_management/packages), theacceleratedMarginCallproperty has been removed from the response. Additionally, two new states have been added to thestateenum:CURE_PERIOD_EXPIREDandDEFAULTED. - For the
Create a new operation(POST /collateral_management/operations) andUpdate an operation(PATCH /collateral_management/operations/{operationId}) endpoints, several unsupported enum values for theactionfield have been removed to reflect currently available actions. - Descriptions have been improved across all listed endpoints for parameters such as
clientReferenceId,pledgorId,curePeriod,ltv,topUpType, and more to provide better guidance.
- For the
Added BID and ASK options for Price Strategy
- Improved: Added
BIDandASKas valid options for thepriceStrategyfield when creating collateral packages and exposures.- Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/packagesPOST /collateral_management/exposures
- Request Body: The
priceStrategyfield in the request body for both endpoints now acceptsBIDandASKas enum values. - Impact: This provides users with more granular control over the pricing strategy, allowing them to specify whether the bid or ask price should be used when creating new collateral packages and exposures.
Improved Filtering for List Orders Endpoint
- Improved order filtering capabilities by adding a new
orderTypesparameter.- Category: Trading
- Endpoint Changed:
GET /trading/orders
- Method: GET
- Path:
/trading/orders
- Parameters: Added the optional
orderTypesquery parameter. This parameter accepts an array of strings to filter orders by their type. Possible values includeLIMIT,MARKET,STOP_LOSS,STOP_LIMIT,TAKE_PROFIT_LIMIT,TWAP,VWAP,PEGGED,POV, andOTHER. - Impact: This change allows for more granular querying of orders, enabling users to retrieve only the specific order types they are interested in.
- Example: A request to retrieve only
LIMITandSTOP_LIMITorders would look like this:GET /v2/trading/orders?orderTypes=LIMIT,STOP_LIMIT.
Streamlined Customer Onboarding Submission
- Improved the customer onboarding workflow by adding an optional
submitparameter.- Category: Onboarding
- Endpoint Changed:
POST /onboarding/customers - Request Body: Added the optional
submit(boolean) parameter to the request body. - Impact: This is a non-breaking change. When
submitis set totrue, the application is created and submitted in a single call, eliminating the need for a separate submission request. - Additional Information: Using this new parameter can help streamline the onboarding process by reducing the number of required API calls.
Added KRAKEN as a Price Source for Collateral Management
- Improved: Added
KRAKENas a supported price source for collateral management.- Category: Collateral Management
- Endpoints Changed:
POST /collateral_management/packagesPOST /collateral_management/exposures
- Request Body: The
priceSourcefield within the request bodies for creating collateral packages and exposures now acceptsKRAKENas a value. - Impact: This provides more flexibility by allowing you to select Kraken as the data source for asset pricing when configuring collateral.