> ## Documentation Index > Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt > Use this file to discover all available pages before exploring further. # API Changelog (2025) > Track updates, additions, and breaking changes to the Anchorage Digital API. **Changelog by year:** [2026](/knowledge-base/api-reference/changelog) · [2025](/knowledge-base/api-reference/changelog-2025) · [2024](/knowledge-base/api-reference/changelog-2024) ## Improved Subaccount Transactions with Staking and Delegation Reward Types **Improved**: Added two new transaction types, `STAKING_REWARD` and `DELEGATION_REWARD`, to provide more detailed transaction information for subaccounts involved in staking. **Category**: Subaccounts **Endpoints Changed**: * `GET /subaccounts/transactions`: Now supports filtering and returns the new `STAKING_REWARD` and `DELEGATION_REWARD` transaction types. * `GET /subaccounts/transactions/{transactionsIds}`: Response `transactionType` field now includes the new reward types. * `GET /subaccounts/transactions/allocations`: Response `transactionType` field now includes the new reward types. **Impact**: This is a non-breaking additive change. The `transactionType` field in responses may now include `STAKING_REWARD` and `DELEGATION_REWARD`, and the `types` query parameter on `GET /subaccounts/transactions` now supports filtering by these new values, enabling more granular tracking of staking-related activity. **Example**: ```json theme={null} { "data": [ { "transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d", "transactionType": "STAKING_REWARD", "status": "POSTED", "createdAt": "2024-08-01T12:00:00.000Z" } ] } ``` ## Improved Rejection Reason for FillOrKill Trading Orders **Improved**: Added the `InvalidCurrencyForFOK` enum value to the `rejectReason` field in the responses for several trading endpoints. **Category**: Trading **Endpoints Changed**: * `POST /trading/order`: Response `rejectReason` now includes `InvalidCurrencyForFOK`. * `POST /trading/async-order`: Response `rejectReason` now includes `InvalidCurrencyForFOK`. * `POST /trading/async-order/cancel`: Response `rejectReason` now includes `InvalidCurrencyForFOK`. **Impact**: This is a non-breaking additive change that provides more specific feedback when a FillOrKill (FOK) order is rejected due to an invalid currency, improving error handling. ## Improved Staking Requests with Asset-Specific Parameters **Improved**: The staking request endpoint now supports specific configuration parameters for different assets; the `parameters` field in the request body is now a structured object. **Category**: Transactions **Endpoint Changed**: * `POST /transactions/stake`: The `parameters` field now accepts a structured object for asset-specific configurations, such as `SOL` and `ETH` staking parameters. **Impact**: This change allows detailed, per-asset configuration of staking requests, enhancing flexibility and control. Support for these asset-specific parameters is still under active development. ## Added Asset-Specific Staking Parameters **Added** a new `parameters` object to the request body for creating stake requests, allowing for asset-specific configurations. **Category**: Transactions **Endpoint Changed**: * `POST /transactions/stake`: Request body now accepts a `parameters` object supporting `stakingProvider` (e.g. `FIGMENT`, `BLOCKDAEMON`), `stakingProviderAddress`, `stakingPositionId`, and `validatorType` (e.g. `0x01` for Pre-Pectra, `0x02` for Post-Pectra). **Impact**: This change provides more granular control over staking operations by allowing users to specify validator details and other asset-specific parameters directly in the request. ## Added Talos as a Price Source Provider for Collateral Management **Added** `TALOS` as a supported price source provider for Collateral Management. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/exposures`: The `priceSourceProvider` field within `assetTrackingConfig` now accepts `TALOS` as a valid enum value. * `POST /collateral_management/packages`: The `priceSourceProvider` field within `collateralAssetsConfig` now accepts `TALOS` as a valid enum value. **Impact**: You can now specify `TALOS` as the provider for consolidating pricing data when creating new collateral exposures and packages. ## Improved Stablecoin Conversion Field Descriptions **Improved**: Clarified the descriptions for the `sourceAssetType` and `destinationAssetType` fields to provide clearer guidance for issuance and redemption operations. **Category**: Stablecoins **Endpoint Changed**: * `POST /stablecoins/conversion`: The description for `sourceAssetType` now states that for issuance the value must be `USD`, and for redemptions it must be the asset being redeemed; the description for `destinationAssetType` now states that for issuance the value must be the stablecoin asset, and for redemptions it must be `USD`. **Impact**: This is a non-breaking documentation change to improve clarity. The endpoint's functionality remains the same. ## Improved Price Source Configuration for Collateral Management **Improved**: Introduced a `priceSourceProvider` field to separate the pricing service provider from the underlying price source, and removed the `KAMINO` enum value from the `priceSource` field. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: Added `priceSourceProvider` to objects within `collateralAssetsConfig`; removed `KAMINO` from `priceSource`. * `POST /collateral_management/exposures`: Added `priceSourceProvider` to `assetTrackingConfig`; removed `KAMINO` from `priceSource`. **Impact**: This change provides more granular control over pricing data by separating the service provider from the underlying price source. `KAMINO` is now specified via the new optional `priceSourceProvider` field instead of `priceSource`. ## Improved Trading Statuses and Tax Tagging Responses **Improved**: Added two new trading trade statuses and updated the response status code for asynchronous tax tagging operations. **Category**: Trading, Tax **Endpoints Changed**: * `POST /trading/quote/accept`: `tradeStatus` enum now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/trades`: `tradeStatus` enum now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/trades/{tradeId}`: `tradeStatus` enum now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/settlements/{settlementId}/trades`: `tradeStatus` enum now includes `PENDINGALLOCATION` and `ALLOCATED`. * `POST /tax/transaction/{transactionId}/tag`: Now returns `202 Accepted` to indicate the request is being processed rather than immediately complete. * `DELETE /tax/transaction/{transactionId}/tag`: Now returns `202 Accepted` to indicate the request is being processed rather than immediately complete. **Impact**: Trading responses now provide clearer insight into the allocation phase of a trade (`PENDINGALLOCATION` means a trade is awaiting client allocation, `ALLOCATED` means it is fully allocated). The tax tagging endpoints now more accurately reflect asynchronous processing with a `202 Accepted` status rather than implying immediate completion. ## Improved Collateral Management Price Sourcing with KAMINO **Improved**: Added `KAMINO` as a new enum value for the `priceSource` field when creating collateral packages and exposures. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: The `priceSource` field within `collateralAssetsConfig` now accepts `KAMINO`. * `POST /collateral_management/exposures`: The `priceSource` field within `assetTrackingConfig` now accepts `KAMINO`. **Impact**: Users can now specify `KAMINO` as the source for price information when creating new collateral packages and exposures. ## Added Price Staleness Configuration for Collateral Packages **Added** an optional `maxStalenessMinutes` field to the request body for creating collateral packages, allowing configuration of the maximum age of an asset's price before it is considered stale. **Category**: Collateral Management **Endpoint Changed**: * `POST /collateral_management/packages`: Each object within `collateralAssetsConfig` now accepts an optional integer `maxStalenessMinutes` field. **Impact**: This is a non-breaking change. If `maxStalenessMinutes` is not provided, the system defaults to 3 minutes. **Example**: ```json theme={null} { "pledgorId": "...", "securedPartyId": "...", "collateralAssetsConfig": [ { "asset": { "type": "ANCHORAGECUSTODY", "assetType": "BTC" }, "weight": "0.85", "liquidationPriority": 1, "maxStalenessMinutes": 5 } ], "priceStrategy": "DEFAULT" } ``` ## Improved Vesting Balances Response with Asset Context **Improved**: The response for getting vesting balances now includes `externalTokenId` and `networkId` for added asset context. **Category**: Vesting **Endpoint Changed**: * `GET /vesting/balances/{allocationId}`: The `balance` object in the response now contains two new required fields: `externalTokenId` (the asset ID assigned by the external provider) and `networkId` (the blockchain network identifier). **Impact**: This is a non-breaking additive change that provides more asset context in vesting balance responses. ## Improved Trading Status Clarity and Added Tax Transaction Tagging **Improved**: Added new endpoints for tagging tax transactions and expanded and clarified trading status fields. **Category**: Tax, Trading **Endpoints Added**: * `POST /tax/transaction/{transactionId}/tag`: Adds a tag to a transaction for tax purposes. * `DELETE /tax/transaction/{transactionId}/tag`: Removes a tag from a transaction. **Endpoints Changed**: * `POST /trading/quote`: `quoteStatus` description clarified. * `POST /trading/quote/accept`: `quoteStatus` and `tradeStatus` descriptions clarified; `tradeStatus` now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/trades`: `tradeStatus` description clarified and expanded. * `GET /trading/trades/{tradeId}`: `tradeStatus` description clarified and expanded. * `GET /trading/settlements/{settlementId}/trades`: `tradeStatus` description clarified and expanded. **Impact**: Users can now organize transactions with tags for easier tax tracking and reporting. The addition of `PENDINGALLOCATION` and `ALLOCATED` trading statuses, along with clearer field descriptions, offers better visibility into the post-execution allocation process. ## Added stakeholderId Parameter to Vesting Balances Endpoint **Added** an optional `stakeholderId` query parameter to the vesting balances endpoint. **Category**: Vesting **Endpoint Changed**: * `GET /vesting/balances/{allocationId}`: New optional `stakeholderId` query parameter can be used to retrieve wallet information for a stakeholder. **Impact**: This is a non-breaking change that improves the ability to retrieve wallet information for newly created stakeholders before any transactions have occurred. ## Improved API Key Permissions with FIAT\_BANKING **Improved**: Added the `FIAT_BANKING` permission type. **Category**: API Key **Endpoint Changed**: * `GET /apikey`: Response may now include `FIAT_BANKING` as a value in the `permission` field within the `permissions` array. **Impact**: API clients that parse the `permissions` array should be updated to handle the new `FIAT_BANKING` enum value. **Example**: ```json theme={null} { "data": { "id": "b5a58566763e77e2d87a53463013981be7c0b048c1c0dd39ba44e77c99bc1351", "permissions": [ { "permission": "READ", "vaultIds": [ "1c920f4241b78a1d483a29f3c24b6c4c" ] }, { "permission": "FIAT_BANKING" } ] } } ``` ## Improved Parameter Descriptions for Delegation Addresses **Improved**: Updated the descriptions for parameters on the delegation addresses endpoint to provide better clarity. **Category**: Transactions **Endpoint Changed**: * `GET /delegation-addresses/{assetType}`: Descriptions for the `assetType`, `afterId`, and `limit` parameters have been improved. **Impact**: This is a non-breaking documentation change with no impact on API functionality. ## Added Endpoint for Listing Delegation Addresses **Added** a new endpoint to list supported delegation addresses for staking. **Category**: Transactions **Endpoint Added**: * `GET /delegation-addresses/{assetType}`: Retrieves a list of supported delegation addresses for a specific asset type. **Impact**: Users can now programmatically discover available delegation addresses for a given asset before initiating staking operations. This endpoint requires the Initiate Staking and Unstaking permission. ## Improved Delegation Address Details with Validator Information **Improved**: The delegation addresses endpoint now includes additional details about the validator for each delegation address. **Category**: Delegation Addresses **Endpoint Changed**: * `GET /delegation-addresses/{assetType}`: Each address object in the `data` array now includes two new required fields: `anchorageValidator` (boolean) and `validatorType` (string). **Impact**: These fields allow you to determine if a delegation address belongs to an Anchorage Digital validator and to identify the type of validator. **Example**: ```json theme={null} { "data": [ { "address": "...", "name": "Validator Name", "anchorageValidator": true, "validatorType": "ENTERPRISE" } ] } ``` ## Improved Collect Requests by Making Amount Optional **Improved**: The `amount` field in the request body for creating a collect request is now optional. **Category**: Transactions **Endpoint Changed**: * `POST /transactions/collect`: The `amount` property is no longer required. **Impact**: You can now omit the `amount` field to collect the full inactive unstaked amount for a given staking position; if not specified, the request defaults to collecting the entire available amount. ## Added Endpoint to List Delegation Addresses **Added** a new endpoint to list supported delegation addresses for a given asset type. **Category**: Addresses **Endpoint Added**: * `GET /delegation-addresses/{assetType}`: Lists supported delegation addresses for the specified asset type. **Impact**: This allows users to programmatically discover valid delegation addresses for specific assets, which can be used to automate staking and delegation operations. **Example**: ```bash theme={null} curl --request GET \ --url 'https://api.anchorage.com/v2/delegation-addresses/ETH' \ --header 'Api-Access-Key: ' ``` ## Added Endpoint to Update Customer Onboarding Applications **Added** the ability to update existing customer onboarding applications before they are submitted for review. **Category**: Onboarding **Endpoint Added**: * `PUT /onboarding/customers/{customerId}`: Updates the data of an existing customer onboarding application by accepting an `entries` array of key-value pairs. **Impact**: Users can now programmatically correct or add information to a customer's onboarding application after initial creation but before final submission. **Example**: ```json theme={null} PUT /onboarding/customers/{customerId} Content-Type: application/json { "entries": [ { "key": "contactEmail", "value": "new.email@example.com" } ] } ``` ## Improved Collateral Exposures by Making Weight Optional **Improved**: The `weight` field within the `assetTrackingConfig` object is now optional when creating a new collateral exposure. **Category**: Collateral Management **Endpoint Changed**: * `POST /collateral_management/exposures`: The `weight` field in `assetTrackingConfig` is no longer required. **Impact**: This change provides greater flexibility by allowing the creation of a collateral exposure without specifying an asset weight. ## Improved Trading Statuses and Staking Full-Amount Operations **Improved**: Added new trading statuses and enhanced unstake and collect operations with a full-amount option. **Category**: Trading, Transactions **Endpoints Changed**: * `POST /trading/quote`: `quoteStatus` enum updated to consistently reflect the quote lifecycle (`OPEN`, `REJECTED`, `EXECUTED`). * `POST /trading/quote/accept`: `tradeStatus` now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/trades`: `tradeStatus` now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/trades/{tradeId}`: `tradeStatus` now includes `PENDINGALLOCATION` and `ALLOCATED`. * `GET /trading/settlements/{settlementId}/trades`: `tradeStatus` now includes `PENDINGALLOCATION` and `ALLOCATED`. * `POST /transactions/unstake`: The `isFullAmount` parameter description clarified to indicate it overrides any provided amount. * `POST /transactions/collect`: New `isFullAmount` boolean parameter added. **Impact**: Clients can track when a trade is awaiting allocation versus fully allocated. You can now set `isFullAmount: true` for unstake and collect operations to process the full available balance, removing the need to first query for the exact amount. ## Improved Staking Position Data and Trading Status Descriptions **Improved**: Added the `inactiveStakedAmount` field to staking position responses and clarified the descriptions for trading status fields. **Category**: Wallets, Trading **Endpoints Changed**: * `GET /wallets/{walletId}/staking/positions`: Response now includes the numeric `inactiveStakedAmount` field (excluding units). * `POST /trading/quote`: `quoteStatus` description clarified. * `POST /trading/quote/accept`: `quoteStatus` and `tradeStatus` descriptions clarified, including the `PENDINGALLOCATION` and `ALLOCATED` states. * `GET /trading/trades`: `tradeStatus` description clarified. * `GET /trading/trades/{tradeId}`: `tradeStatus` description clarified. * `GET /trading/settlements/{settlementId}/trades`: `tradeStatus` description clarified. **Impact**: Users can now retrieve the inactive staked amount for a given staking position for more detailed insight into staking activity. The trading status description updates are a non-breaking documentation enhancement that provides clearer explanations of the quote and trade lifecycle. ## Improved Tax Form Responses with Additional Details **Improved**: Enhanced tax form responses with additional details for each tax form. **Category**: Tax **Endpoints Changed**: * `GET /tax/subaccounts/{subaccountId}/forms`: Each form object now includes `id`, `createdDate`, `year`, `revision`, `revisionType`, and `isFiled` fields. * `GET /tax/clients/{customerId}/forms`: Each form object now includes `id`, `createdDate`, `year`, `revision`, `revisionType`, and `isFiled` fields. **Impact**: This is a non-breaking change that provides richer data for tax form management and tracking. **Example**: ```json theme={null} { "data": [ { "subaccountId": "your-subaccount-id", "forms": [ { "formType": "1099B", "downloadLink": "https://api.anchorage.com/download/link", "id": "d290f1ee-6c54-4b01-90e6-d701748f0851", "createdDate": "2023-02-10T08:30:00Z", "year": 2022, "revision": 1, "revisionType": "Original", "isFiled": true } ] } ] } ``` ## Improved Descriptions for Creating Trusted Destinations **Improved**: Updated the descriptions for fields in the request body to provide better clarity. **Category**: Trusted Destinations **Endpoint Changed**: * `POST /trusted_destinations`: Descriptions for the `trustedDestinations` array and the `name` property within array items have been improved. **Impact**: This is a non-breaking documentation change to improve developer experience. No functional changes have been made. ## Improved Collect Request Body with Source and Idempotency **Improved**: The request body for creating a collect request now includes `source`, `description`, and an idempotency key. **Category**: Transactions **Endpoint Changed**: * `POST /transactions/collect`: Request body now requires a `source` object specifying the wallet to collect from, and adds optional `description` and `idempotentId` fields. The `201 Created` response now returns an `application/json` payload. **Impact**: This is a breaking change — the `source` field is now required. Clients using this endpoint must update their integration to include the `source` object. ## Improved Error Handling for Asynchronous Orders **Improved**: Added the `InvalidAccountsInAllocation` reject reason for asynchronous orders that fail due to subaccount allocation issues. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: Response `rejectReason` now includes `InvalidAccountsInAllocation`. * `POST /trading/async-order/cancel`: Response `rejectReason` now includes `InvalidAccountsInAllocation`. **Impact**: You will now receive a more specific error reason if an asynchronous order or its cancellation is rejected because of invalid account information in the allocation. ## Improved Stablecoin Conversion Creation Response **Improved**: The `201 Created` response for creating a stablecoin conversion now supports a new authorization workflow. **Category**: Stablecoins **Endpoint Changed**: * `POST /stablecoins/conversion`: The response now returns a required `authorizationOperationId` instead of `conversionId`; `conversionId` is now optional in the response. **Impact**: This is a breaking change. Use the new `authorizationOperationId` to track the authorization status of the stablecoin conversion request. ## Improved Collateral Management with Interest Paydown and Accrual Actions **Improved**: Added `INTEREST_PAYDOWN` and `INTEREST_ACCRUAL` as new valid actions for Collateral Management operations. **Category**: Collateral Management **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}`: `action` field now supports `INTEREST_PAYDOWN` and `INTEREST_ACCRUAL`. * `POST /collateral_management/operations`: `action` field now supports `INTEREST_PAYDOWN` and `INTEREST_ACCRUAL`. * `GET /collateral_management/operations`: `action` field in responses now supports `INTEREST_PAYDOWN` and `INTEREST_ACCRUAL`. **Impact**: This enables users to programmatically record interest paydown and accrual activities on their exposures, allowing for more detailed tracking of loan activities. ## Added Endpoints for Retrieving Account Statements **Added** new endpoints for listing and downloading account statements. **Category**: Statements **Endpoints Added**: * `GET /statement-types`: Lists available statement types. * `GET /statements`: Lists generated statements for your account. * `GET /statements/{statementId}`: Gets details for a specific statement by its ID. * `GET /statements/{statementId}/download`: Downloads a specific statement file. **Impact**: Users can now programmatically access and download their account statements, enhancing reporting and record-keeping capabilities. ## Added Webhook Notifications for Real-Time Event Updates **Added** support for Webhook Notifications to receive real-time updates on account activity. **Category**: Webhook Notifications **Endpoints Added**: * `GET /webhook/validation-key`: Retrieves the key used to validate webhook payload signatures. * `GET /webhook/event-types`: Lists all available event types you can subscribe to. * `POST /webhook/endpoints`: Creates a new webhook endpoint. * `GET /webhook/endpoints`: Lists your webhook endpoints. * `GET /webhook/endpoints/{endpointId}`: Gets a specific webhook endpoint. * `PATCH /webhook/endpoints/{endpointId}`: Updates a webhook endpoint. * `POST /webhook/endpoints/{endpointId}/subscriptions`: Subscribes an endpoint to an event type. * `GET /webhook/endpoints/{endpointId}/subscriptions`: Lists an endpoint's event subscriptions. * `DELETE /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId}`: Removes an endpoint's subscription to an event type. **Impact**: Users can now build more efficient, event-driven integrations by subscribing to notifications for events such as `withdrawal.initiated` or `transfer.completed`, eliminating the need for polling. An API key with the Configure Webhooks permission is required to use these endpoints. **Example**: ```json theme={null} [ { "url": "https://your-domain.com/transaction-webhooks", "description": "Endpoint for receiving transaction event webhooks", "subscriptions": [ { "eventTypeId": "withdrawal.initiated" } ], "publicKey": "-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEeg+pxTCsjew/+7IK4+Vw5zyHDnMW7bzn\nsClhuYIKjXF8EJ1lfyZC2VPVullBKgvHRzNMfC1KkF2LIoRp2ibcWQ==\n-----END PUBLIC KEY-----" } ] ``` ## Improved Trading Orders with Subaccount Allocation Details **Improved**: Trading endpoints now support and return subaccount allocation details. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: Request body now accepts an `allocation` array specifying how the order should be allocated across subaccounts. * `POST /trading/async-order/cancel`: Response now includes a detailed `allocation` object. * `POST /trading/order`: Response now includes a detailed `allocation` object. * `GET /trading/orders`: Response now includes a detailed `allocation` object. * `GET /trading/orders/{orderId}`: Response now includes a detailed `allocation` object. **Impact**: This provides greater flexibility and transparency for users managing multiple subaccounts, enabling programmatic allocation of orders and detailed reporting on executed trades. The `allocation` object includes `subaccountId`, `quantity`, `fee`, and `executionId`. **Example**: ```json theme={null} "allocation": [ { "subaccountId": "343b6c83-6d91-4f13-9982-2109abd2dbb0", "quantity": "5000.00" }, { "subaccountId": "905272f0-52f9-404e-b6cd-ad879e671790", "quantity": "5000.00" } ] ``` ## Improved Gas Station Fee Option for Transfers and Withdrawals **Improved**: Clarified the `useGasStation` parameter for handling network fees on transfers and withdrawals. **Category**: Transactions, Transfers **Endpoints Changed**: * `POST /transactions/withdrawal`: The optional boolean `useGasStation` field is now more clearly documented. * `POST /transfers`: The optional boolean `useGasStation` field is now more clearly documented. **Impact**: Setting `useGasStation` to `true` allows the Anchorage Digital gas station to pay for network fees, simplifying fee management for supported asset types and organizations. If the parameter is omitted, it defaults to `false`. **Example**: ```json theme={null} { "assetType": "ETH", "amount": "5.0", "idempotentId": "e8a7f9b0-9c8d-4e6f-a1b2-c3d4e5f6a7b8", "source": { "id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "WALLET" }, "destination": { "id": "0x1234567890123456789012345678901234567890", "type": "ADDRESS" }, "useGasStation": true } ``` ## Added Collect Endpoint and Improved Staking Operations **Added** a new transaction type for collect requests and enhanced staking and unstaking requests with a full-amount option. **Category**: Transactions **Endpoint Added**: * `POST /transactions/collect`: Creates a collect request. **Endpoints Changed**: * `POST /transactions/stake`: Request body now accepts an optional boolean `isFullAmount` field. * `POST /transactions/unstake`: Request body now accepts an optional boolean `isFullAmount` field. **Impact**: Users can now programmatically create collect requests. Setting `isFullAmount` to `true` on stake and unstake requests performs the operation for the full available amount, removing the need for clients to manually specify the quantity. ## Added LTV Rounding Precision to Collateral Package Creation **Added** a new `ltvRoundingPrecision` field for specifying the number of decimal places to round Loan-to-Value (LTV) ratios. **Category**: Collateral Management **Endpoint Changed**: * `POST /collateral_management/packages`: Request body now accepts an optional `ltvRoundingPrecision` field. **Impact**: This provides greater control and precision over how LTV is calculated for new collateral packages. ## Improved Stablecoin Conversion Request Body **Improved**: Standardized how amounts and idempotency are handled when creating a stablecoin conversion. **Category**: Stablecoins **Endpoint Changed**: * `POST /stablecoins/conversion`: Removed the optional `decimalAmount` and `idempotentId` fields; added required fields `amount` (string) and `idempotencyKey` (string). **Impact**: This is a breaking change. Any integrations using this endpoint must be updated to send the new required fields `amount` and `idempotencyKey`. **Example**: *Previous Request Structure:* ```json theme={null} { "decimalAmount": "100.00", "idempotentId": "some-uuid-v4-string" } ``` *New Request Structure:* ```json theme={null} { "amount": "100.00", "idempotencyKey": "your-unique-key-string" } ``` ## Improved Trading and Quote Status Descriptions **Improved**: Updated the `tradeStatus` and `quoteStatus` fields across multiple Trading endpoints with more detailed descriptions and a comprehensive list of possible values. **Category**: Trading **Endpoints Changed**: * `POST /trading/quote`: `quoteStatus` description expanded. * `POST /trading/quote/accept`: `tradeStatus` and `quoteStatus` descriptions expanded. * `GET /trading/settlements/{settlementId}/trades`: `tradeStatus` description expanded. * `GET /trading/trades`: `tradeStatus` description expanded. * `GET /trading/trades/{tradeId}`: `tradeStatus` description expanded. **Impact**: This change provides greater clarity on the lifecycle of trades and quotes. The `tradeStatus` field now documents the following possible values: `PENDING`, `REJECTED`, `CANCELED`, `EXECUTED`, `SETTLING`, `SETTLED`, `PENDINGALLOCATION`, and `ALLOCATED`. ## Improved Trading API Documentation Clarity **Improved**: Enhanced documentation for several Trading endpoints with clearer explanations, more detailed examples, and updated field descriptions. **Category**: Trading **Endpoints Changed**: * `GET /trading/accounts/{accountId}`: Clarified `404 Not Found` response description. * `POST /trading/async-order`: Description clarity improvements. * `POST /trading/order`: Description clarity improvements. * `GET /trading/pairs`: Enhanced description of the `referenceData` object. * `POST /trading/quote`: Added comprehensive request body examples for `BUY`, `SELL`, and `TWOWAY` scenarios; clarified `quoteStatus` description. * `POST /trading/quote/accept`: Improved description of `allowedSlippage` and `vaultID`, including a detailed example of how `allowedSlippage` functions. * `GET /trading/settlements/{settlementId}/trades`: Clarified `tradeStatus` and `settlementStatus` descriptions and the `404 Not Found` response. * `GET /trading/trades`: Clarified `tradeStatus` description. * `GET /trading/trades/{tradeId}`: Clarified `tradeStatus` description. * `GET /trading/settlements`: Clarified `settlementStatus` description. * `GET /trading/settlements/{settlementId}`: Clarified `settlementStatus` description; updated `price` field description to explain its composition and asynchronous availability. **Impact**: These are documentation-only changes to improve clarity and provide better examples. There are no functional changes to the API endpoints. ## Improved Async Order Rejection with OrderNotCancelable Reason **Improved**: Added the `OrderNotCancelable` value to the `rejectReason` enum for asynchronous order responses. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: `rejectReason` now includes `OrderNotCancelable`. * `POST /trading/async-order/cancel`: `rejectReason` now includes `OrderNotCancelable`. **Impact**: This change provides more specific feedback when an attempt to place or cancel an asynchronous order is rejected because the order is no longer in a modifiable state (e.g., already filled or canceled). ## Improved Transaction Filtering with New Reward Types **Improved**: The `types` query parameter for listing transactions now supports more granular filtering by reward type. **Category**: Transactions **Endpoint Changed**: * `GET /transactions`: The `types` query parameter now accepts `DELEGATION_REWARD`, `STAKING_REWARD`, `RESTAKING_REWARD`, and `ALLUVIAL_STAKING_REWARD`. **Impact**: Users can now retrieve a more specific list of transactions by filtering for various reward types, which helps in auditing and reconciling staking activities. **Example**: ``` GET /v2/transactions?types=STAKING_REWARD,DELEGATION_REWARD ``` ## Added Atlas Settlement Network, Collateral Management, Stablecoins, Tax, Trusted Destinations, and Webhook Endpoints **Added** a broad set of new endpoints spanning the Atlas Settlement Network, Collateral Management, Stablecoins, Tax Reporting, Trusted Destinations, and Webhook Notifications, alongside significant enhancements to core custody operations for vaults, wallets, transactions, and transfers. **Category**: Atlas Settlement Network, Collateral Management, Stablecoins, Tax, Trusted Destinations, Webhook Notifications, Custody **Endpoints Added**: * `GET /atlas/directory/counterparties`: Lists counterparties on the Atlas Settlement Network. * `GET /atlas/directory/counterparties/{counterpartyId}`: Gets a specific counterparty. * `GET /atlas/directory/participants`: Lists participants on the Atlas Settlement Network. * `POST /atlas/settlements`: Proposes a new settlement. * `GET /atlas/settlements`: Lists settlements. * `GET /atlas/settlements/{settlementId}`: Gets a specific settlement. * `POST /atlas/settlements/{settlementId}/accept`: Accepts a settlement proposal. * `POST /atlas/settlements/{settlementId}/authorize`: Authorizes a settlement. * `POST /atlas/settlements/{settlementId}/reject`: Rejects a settlement proposal. * `GET /collateral_management/exposures`: Lists collateral exposures. * `POST /collateral_management/exposures`: Creates a collateral exposure. * `GET /collateral_management/operations`: Lists collateral operations. * `POST /collateral_management/operations`: Creates a collateral operation. * `PATCH /collateral_management/operations/{operationId}`: Updates a collateral operation. * `GET /collateral_management/packages`: Lists collateral packages. * `POST /collateral_management/packages`: Creates a collateral package. * `PATCH /collateral_management/packages/{packageId}`: Updates a collateral package. * `POST /stablecoins/conversion`: Creates stablecoin conversions, including issuance and redemption. * `GET /tax/inventory/summary/{subaccountId}`, `PATCH /tax/transaction/{transactionId}`, `GET /tax/clients/{customerId}/forms`, and more: A full suite of endpoints to fetch tax transactions, gains, inventory, and forms, and to update cost basis. * `GET /trusted_destinations`, `POST /trusted_destinations`, `DELETE /trusted_destinations/{creationRequestId}/cancel`, and more: Create, list, and manage the lifecycle of trusted destinations. * `GET /webhook/endpoints`: Lists webhook endpoints. * `POST /webhook/endpoints`: Creates a webhook endpoint. * `GET /webhook/endpoints/{endpointId}`: Gets a webhook endpoint. * `PATCH /webhook/endpoints/{endpointId}`: Updates a webhook endpoint. * `GET /webhook/endpoints/{endpointId}/subscriptions`: Lists an endpoint's subscriptions. * `POST /webhook/endpoints/{endpointId}/subscriptions`: Subscribes an endpoint to an event type. * `DELETE /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId}`: Removes an event subscription. * `GET /webhook/event-types`: Lists available webhook event types. * `GET /webhook/validation-key`: Retrieves the webhook payload validation key. **Endpoints Changed**: * `GET /vaults`, `POST /vaults/{vaultId}/wallets`, `GET /wallets`, `GET /wallets/{walletId}/staking/positions`, `GET /wallets/{walletId}/staking/rewards`: Expanded for comprehensive listing and creation, including access to staking data. * `GET /vaults/{vaultId}/addresses`, `POST /wallets/{walletId}/addresses`: Expanded to list and provision new deposit addresses. * `POST /transactions/stake`, `POST /transactions/unstake`, `POST /transactions/withdrawal`: Expanded to initiate staking and withdrawal operations. * `POST /transfers`, `GET /transfers`, `DELETE /transfers/{transferId}`: Expanded to create, list, and cancel automated asset transfers. **Impact**: This major update introduces a wide range of new capabilities to programmatically manage assets, automate workflows, and access detailed financial data across custody, settlement, collateral, stablecoin, tax, and webhook operations. ## Added 422 Error Response for Collateral Exposure Creation **Added** a `422 Unprocessable Entity` error response to the endpoint for creating a new collateral exposure. **Category**: Collateral Management **Endpoint Changed**: * `POST /collateral_management/exposures`: May now return a `422 Unprocessable Entity` response when a request is syntactically correct but cannot be processed due to semantic or business logic errors. **Impact**: API clients should be prepared to handle this new `422` status code for this endpoint. ## Added Endpoint for Stablecoin Conversions **Added** a new endpoint to enable programmatic conversion between stablecoins. **Category**: Stablecoin Conversions **Endpoint Added**: * `POST /stablecoins/conversion`: Creates a stablecoin conversion. **Impact**: This new functionality allows users to convert between different stablecoins directly through the API. ## Added Trusted Destination Support for Transfers and Withdrawals **Added** support for `TRUSTED_DESTINATION` as a valid destination type, allowing you to specify a pre-approved trusted destination when creating transfers and withdrawals. **Category**: Transfers, Transactions **Endpoints Changed**: * `POST /transfers`: `destination.type` now accepts `TRUSTED_DESTINATION`. * `POST /transactions/withdrawal`: `destination.type` now accepts `TRUSTED_DESTINATION`. * `GET /transfers`: Response now reflects the `TRUSTED_DESTINATION` destination type. * `GET /transfers/{transferId}`: Response now reflects the `TRUSTED_DESTINATION` destination type. **Impact**: You can now initiate transfers and withdrawals to pre-configured trusted destinations by providing their unique ID, simplifying transactions to frequently used external addresses. **Example**: ```json theme={null} { "assetType": "BTC", "amount": "1.5", "source": { "id": "3d293c0d64c703023692216e9b4f5280", "type": "WALLET" }, "destination": { "id": "d1ae1416-ebd7-11ea-adc1-0242ac120002", "type": "TRUSTED_DESTINATION" } } ``` ## Improved Tax Inventory Response Field Casing **Improved**: Updated the `AverageUnitCost` field to `averageUnitCost` in the tax inventory response for casing consistency. **Category**: Tax **Endpoint Changed**: * `GET /tax/inventory/{subaccountId}/{assetTypeId}`: Response field renamed from `AverageUnitCost` to `averageUnitCost`. **Impact**: This is a breaking change. Integrations that parse the `AverageUnitCost` field must be updated to use the new `averageUnitCost` field name. **Example**: *Previous Response Structure:* ```json theme={null} { "AverageUnitCost": "50000.00" } ``` *New Response Structure:* ```json theme={null} { "averageUnitCost": "50000.00" } ``` ## Improved API Key Permissions and Signature Documentation **Improved**: Added a new API key permission for converting stablecoins and clarified signature header documentation for staking endpoints. **Category**: API Key, Transactions **Endpoints Changed**: * `GET /apikey`: Response `permissions` array may now include the new `CONVERT_STABLECOINS` permission. * `POST /transactions/stake`: `Api-Signature` header documentation clarified. * `POST /transactions/unstake`: `Api-Signature` header documentation clarified. **Impact**: The `CONVERT_STABLECOINS` permission may now appear in `GET /apikey` responses if enabled for the API key. The signature header documentation update is documentation-only and does not affect API functionality. ## Added Wallet Search by Address **Added** a new `searchByAddress` query parameter to find wallets by a full or partial address they contain. **Category**: Wallets **Endpoint Changed**: * `GET /wallets`: New `searchByAddress` query parameter, requiring a minimum of 3 characters. **Impact**: Users can now more easily locate specific wallets by using an address as a search term. **Example**: ``` GET /v2/wallets?searchByAddress=0xAbC123 ``` ## Added Strategy Parameters to Trading Order Responses **Added** a `strategyParams` object to trading order responses to provide more detail on strategy-based orders. **Category**: Trading **Endpoints Changed**: * `GET /trading/orders`: Response now includes a `strategyParams` object containing `triggerPrice` and `endTime` for applicable order types. * `GET /trading/orders/{orderId}`: Response now includes a `strategyParams` object containing `triggerPrice` and `endTime` for applicable order types. **Impact**: This is a non-breaking change that provides visibility into the parameters governing strategy-based orders (e.g., stop-limit, take-profit). ## Improved Error Handling for Collateral Package Creation **Improved**: Added a new `422 Unprocessable Entity` response to provide more specific error feedback when creating a new collateral package. **Category**: Collateral Management **Endpoint Changed**: * `POST /collateral_management/packages`: May now return a `422 Unprocessable Entity` response. **Impact**: API clients should be prepared to handle the `422 Unprocessable Entity` status code, which indicates the request syntax is correct but the server cannot process it due to semantic errors or failed business logic validation. ## Added Endpoint to Cancel Trusted Destination Creation **Added** a new endpoint to cancel a pending Trusted Destination creation request. **Category**: Trusted Destinations **Endpoint Added**: * `DELETE /trusted_destinations/{creationRequestId}/cancel`: Cancels a pending Trusted Destination creation request. The `creationRequestId` corresponds to the `idempotentId` provided in the initial `POST /trusted_destinations` request. **Impact**: This provides users the ability to programmatically cancel a Trusted Destination creation workflow before it is finalized, useful for correcting errors or aborting requests that are no longer needed. ## Improved Standardization of rejectReason Enum for Async Orders **Improved**: Standardized the `rejectReason` enum values for asynchronous trading orders to provide clearer, more consistent error codes. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: `rejectReason` enum standardized — removed `ErrInvalidLimitPriceForSell`, `ErrInvalidLimitPriceForBuy`, `ErrInvalidTriggerPrice`, and `ErrInvalidLimitPrice`; added `InvalidLimitPrice` and `InvalidTriggerPrice`. * `POST /trading/async-order/cancel`: Same `rejectReason` enum changes as above. **Impact**: Clients who parse the `rejectReason` field for specific error reasons should update their logic to use the new enum values. ## Improved Async Order Rejection with ErrInvalidLimitPrice Reason **Improved**: Added the `ErrInvalidLimitPrice` enum value to the `rejectReason` field for async order endpoints. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: `rejectReason` now includes `ErrInvalidLimitPrice`. * `POST /trading/async-order/cancel`: `rejectReason` now includes `ErrInvalidLimitPrice`. **Impact**: When an async order is rejected due to an invalid limit price, the API response now includes this more specific reason, providing clearer feedback for failed order operations. ## Improved Subaccount Balances with Detailed Entry Breakdown **Improved**: Subaccount details responses now include a granular breakdown of balances via a new `entries` field. **Category**: Subaccounts **Endpoints Changed**: * `GET /subaccounts/customers/accounts`: Each object in the `balances` array now contains an `entries` array, with each entry providing an `amount` and `description` for a component of the total balance (e.g., Posted, Pending). * `GET /subaccounts/customers/{customerId}/accounts`: Same `entries` addition to the `balances` array. **Impact**: This is a non-breaking change. Clients will receive additional, more detailed balance information in the API response. **Example**: ```json theme={null} "balances": [ { "assetType": "USD", "totalBalance": "1000.00", "entries": [ { "amount": "950.00", "description": "Posted Balance" }, { "amount": "50.00", "description": "Pending Balance" } ] } ] ``` ## Deprecated VAULT Resource Type for Transfers and Withdrawals **Deprecated**: The use of `VAULT` as a resource `type` for identifying the `source` and `destination` of funds. Users must specify a `WALLET` ID instead. **Category**: Transfers, Transactions, Vaults, Wallets **Endpoints Changed**: * `POST /transactions/withdrawal`: `source.type`/`destination.type` no longer accept `VAULT`; use `WALLET`. * `POST /transfers`: `source.type`/`destination.type` no longer accept `VAULT`; use `WALLET`. * `GET /transfers`: Response reflects that wallet resource `type` is always `WALLET`. * `GET /transfers/{transferId}`: Response reflects that wallet resource `type` is always `WALLET`. * `GET /vaults`: Response reflects the deprecation. * `GET /vaults/{vaultId}`: Response reflects the deprecation. * `GET /vaults/{vaultId}/wallets`: Response reflects the deprecation. * `POST /vaults/{vaultId}/wallets`: Response reflects the deprecation. * `GET /wallets`: Response reflects that wallet resource `type` is always `WALLET`. * `GET /wallets/{walletId}`: Response reflects that wallet resource `type` is always `WALLET`. **Impact**: This is a breaking change. Integrations that create transfers or withdrawals by specifying a `VAULT` ID must be updated to use a specific `WALLET` ID; the previous behavior of defaulting to a vault's default wallet is removed. This ensures all asset movements explicitly specify which wallet within a vault should be used. **Example**: *Previous Request Structure:* ```json theme={null} { "source": { "id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "VAULT" } } ``` *New Request Structure:* ```json theme={null} { "source": { "id": "3d293c0d64c703023692216e9b4f5280", "type": "WALLET" } } ``` ## Improved Trusted Destinations Response Structure **Improved**: The response for listing trusted destinations now provides more detailed information — the `owners` array has been replaced by a structured `owner` object, and new `name` and `description` fields have been added. **Category**: Trusted Destinations **Endpoint Changed**: * `GET /trusted_destinations`: `owners` array replaced with an `owner` object; added `name` and `description` fields. **Impact**: This is a breaking change. Integrations that previously parsed the `owners` array must be updated to use the new `owner` object. **Example**: *Previous Response Structure:* ```json theme={null} { "id": "td_123", "owners": ["cust_abc"] } ``` *New Response Structure:* ```json theme={null} { "id": "td_123", "name": "My Destination", "description": "Coinbase wallet", "owner": { "id": "cust_abc", "type": "CUSTOMER" } } ``` ## Improved Async Order Parameters and Content Type **Improved**: Changed the request body content type and clarified the `parameters` property for asynchronous orders. **Category**: Trading **Endpoint Changed**: * `POST /trading/async-order`: Request body content type changed to `application/json`. The `parameters` property is now specifically for `STOP_LOSS`, `STOP_LIMIT`, and `TAKE_PROFIT_LIMIT` order types, including optional `endTime` and required `triggerPrice` parameters. **Impact**: This clarifies the use of the `parameters` property and formalizes the request body content type. ## Improved Wallet Filtering Parameter Naming **Improved**: Renamed the `assetTypeId` query parameter to `assetType` for wallet listing endpoints. **Category**: Wallets **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets`: `assetTypeId` query parameter replaced with `assetType`. * `GET /wallets`: `assetTypeId` query parameter replaced with `assetType`. **Impact**: Integrations filtering wallets by asset type must update their query parameter name from `assetTypeId` to `assetType`. ## Added networkId and assetTypeId Filters to Wallet Endpoints **Added** `networkId` and `assetTypeId` query filters to the wallet listing endpoints. **Category**: Wallets **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets`: New optional `networkId` and `assetTypeId` query parameters filter results to wallets matching the given network or asset type. * `GET /wallets`: New optional `networkId` and `assetTypeId` query parameters filter results to wallets matching the given network or asset type. **Impact**: Users can now narrow down wallet listings by network or asset type without additional client-side filtering. ## Added Endpoint to Update Collateral Packages **Added** a new endpoint to update an existing collateral package. **Category**: Collateral Management **Endpoint Added**: * `PATCH /collateral_management/packages/{packageId}`: Updates an existing collateral package. **Impact**: Allows updating existing collateral packages. ## Added RFQ Order Type to Trading Endpoints **Added** `RFQ` as a new order type on Trading endpoints. **Category**: Trading **Endpoints Changed**: * `GET /trading/orders`: `orderType` field in responses now includes `RFQ` as a possible value. * `GET /trading/orders/{orderId}`: `orderType` field in responses now includes `RFQ` as a possible value. **Impact**: The list of returned orders, and any individual order retrieved, can now include orders with the `RFQ` type. ## Added Expired Status to Trusted Destinations Workflow **Added** `Expired` as a new status value in the Trusted Destination creation request workflow. **Category**: Trusted Destinations **Endpoint Changed**: * `GET /trusted_destinations/{creationRequestId}/status`: `status` field may now return `Expired`. **Impact**: A response with status `Expired` indicates that the Trusted Destination creation request has expired. ## Added Collateral Exposures Endpoint and Updated Collateral Packages **Added** support for creating collateral exposures, and updated the request body for creating collateral packages. **Category**: Collateral Management **Endpoint Added**: * `POST /collateral_management/exposures`: Creates a collateral exposure. **Endpoint Changed**: * `POST /collateral_management/packages`: Removed the required `internalName` property; changed the `collateralAssetsConfig` array. **Impact**: Users can now create collateral exposures via the API, and collateral package creation reflects the updated request body structure. ## Added internalName and priceStrategy to Collateral Package Creation **Added** an optional `internalName` field and a required `priceStrategy` field to collateral package creation. **Category**: Collateral Management **Endpoint Changed**: * `POST /collateral_management/packages`: Request body now accepts an optional `internalName` (string) for internal tracking, and requires a `priceStrategy` (string) field specifying the pricing strategy, with `DEFAULT` as a valid enum value. **Impact**: Users can now assign an internal tracking name to a collateral package and must specify a pricing strategy when creating one. ## Added Collateral Package Creation and Improved Package Retrieval **Added** a new endpoint to create collateral packages, and expanded the response for retrieving collateral packages with more detailed level configuration. **Category**: Collateral Management **Endpoint Added**: * `POST /collateral_management/packages`: Creates a new collateral package. **Endpoint Changed**: * `GET /collateral_management/packages`: The `acceleratedMarginCall` and `critical` objects now include `returnToLtv` and `warningLtv` properties, with the `critical` object now required; the `action` enum for these objects now includes `NONE`, `PARTIAL`, `FULL`, and `SWEEP`. The `marginCall` object adds `curePeriod`, `curePeriodProtection`, and `topUpType` properties with the same expanded `action` enum. The `marginReturn` object adds a `returnToLtv` property with an `action` enum of `NONE` and `SWEEP`. **Impact**: Clients can now create collateral packages via the API and retrieve significantly more detailed information about collateral package levels and their configurations. ## Added GAS\_STATION Transaction Type **Added** `GAS_STATION` as a new `transactionType` enum value. **Category**: Transactions **Endpoints Changed**: * `GET /transactions`: `transactionType` field now includes `GAS_STATION`. * `GET /transactions/{transactionId}`: `transactionType` field now includes `GAS_STATION`. **Impact**: The `transactionType` field in responses can now be `GAS_STATION`, representing funds received from the gas station to cover network fees, providing more granular information about transaction types. ## Added Owners Field to Trusted Destinations Response **Added** an `owners` field to the Trusted Destinations response. **Category**: Trusted Destinations **Endpoint Changed**: * `GET /trusted_destinations`: Each object in the `data` array now includes an `owners` field, an array of strings representing the owners of the trusted destination. **Impact**: This change provides more information about the ownership of trusted destinations. **Example**: ```json theme={null} { "data": [ { "id": "some-id", "type": "crypto", "crypto": { "address": "some-address", "networkId": "some-network", "assetType": "some-asset", "isNetworkLevel": false }, "owners": ["owner1", "owner2"] } ], "page": { "next": null } } ``` ## Added REHYPE\_IN and REHYPE\_OUT Actions for Collateral Management **Added** `REHYPE_IN` and `REHYPE_OUT` as new valid actions for collateral package operations, and clarified the documentation for the `action` property. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/operations`: `action` field now supports `REHYPE_IN` and `REHYPE_OUT`. * `PATCH /collateral_management/operations/{operationId}`: `action` field now supports `REHYPE_IN` and `REHYPE_OUT`. * `GET /collateral_management/operations`: `action` field in responses now supports `REHYPE_IN` and `REHYPE_OUT`. **Impact**: This expands the available actions for collateral package operations. `REHYPE_IN` and `REHYPE_OUT` operations do not change the balance of the collateral package used for LTV monitoring. The documentation for the `action` property was also clarified, noting that `CLOSE_RETURN` is not currently supported and that write operations for liquidations are also not supported. ## Improved Trusted Destination Status Granularity **Improved**: Updated the possible values for the `status` property to provide more granularity into the Trusted Destination creation workflow. **Category**: Trusted Destinations **Endpoint Changed**: * `GET /trusted_destinations/{creationRequestId}/status`: `status` field now returns one of `Initiated`, `Generating Docusign`, `Pending DocuSign Signature`, `Trusted Destination Operation In Progress`, `Needs Quorum Approval`, `Anchorage Risk Review`, `Linking Trusted Destination`, `Complete`, `Failed`, `Rejected`, or `Canceled`. **Impact**: Users will now receive more detailed status updates during the Trusted Destination creation process — for example, `Pending DocuSign Signature` during the signature step, or `Needs Quorum Approval` while awaiting internal approvals. ## Added Vesting Balances Endpoint **Added** a new endpoint to get vesting balances for an allocation. **Category**: Vesting **Endpoint Added**: * `GET /vesting/balances/{allocationId}`: Retrieves vesting balances for a given allocation. **Impact**: This is applicable only to vesting partners to whom Anchorage delivers an `allocationId`. For aggregate investor vesting balances, see `unvestedUnstakeableBalance` and `unvestedBalance` in any balance endpoint (e.g. `GET /wallets`). ## Added Async Order Endpoint and Expanded Order Types **Added** new endpoints to place and cancel asynchronous trading orders, and expanded the set of supported order types. **Category**: Trading **Endpoints Added**: * `POST /trading/async-order`: Places an async order (Market or Limit; currently only FillOrKill is supported). One of `accountId` or `subaccountId` must be specified, but not both. * `POST /trading/async-order/cancel`: Cancels an async order. **Endpoints Changed**: * `GET /trading/orders`: `orderType` now includes `STOP_LIMIT`, `TAKE_PROFIT_LIMIT`, `STOP_LOSS`, `TWAP`, `VWAP`, `PEGGED`, `POV`, and `OTHER`; `orderStatus` now includes `PENDING_CANCEL`. * `GET /trading/orders/{orderId}`: `orderType` now includes `STOP_LIMIT`, `TAKE_PROFIT_LIMIT`, `STOP_LOSS`, `TWAP`, `VWAP`, `PEGGED`, `POV`, and `OTHER`. **Impact**: This enables placing and canceling orders asynchronously, expands the range of order types available for trading, and the new `PENDING_CANCEL` status indicates that a cancellation request has been received for an async order. ## Improved Webhook Endpoints with Public Key Support **Improved**: Added `publicKey` support across webhook endpoint management, and added a new API key permission for configuring webhooks. **Category**: Webhook Notifications, API Key **Endpoints Changed**: * `GET /webhook/endpoints`: Response now includes a `publicKey` property for each endpoint. * `POST /webhook/endpoints`: Request body now accepts an optional `publicKey` field. * `GET /webhook/endpoints/{endpointId}`: Response now includes a `publicKey` property. * `PATCH /webhook/endpoints/{endpointId}`: Request body now accepts a `publicKey` property, allowing it to be updated. * `GET /apikey`: `permissions` array now supports a new `CONFIGURE_WEBHOOKS` permission, which controls access to webhook configuration endpoints. **Impact**: Clients can now set and retrieve a public key when creating or managing webhook endpoints. The new `CONFIGURE_WEBHOOKS` permission must be granted to an API key to create or manage webhook endpoints. ## Added Trusted Destinations Status Endpoint **Added** a new endpoint to track the status of a Trusted Destination creation request. **Category**: Trusted Destinations **Endpoint Added**: * `GET /trusted_destinations/{creationRequestId}/status`: Retrieves the status of a Trusted Destination creation request, using the `creationRequestId` path parameter (the idempotent ID provided in the Create Trusted Destination request). **Impact**: Allows users to track the progress of Trusted Destination creation requests. **Example**: ``` GET /trusted_destinations/1ca86e65-4340-4876-85f4-8334852b9c43/status ``` ## Added Create Allocations Endpoint for Wealth Management **Added** the ability to create new allocations between subaccounts of the same Program Customer. **Category**: Subaccounts **Endpoint Added**: * `POST /subaccounts/transactions/allocations`: Creates new allocations between subaccounts of the same Program Customer. This is a transactional operation — either all allocations are created successfully, or none are. A maximum of 100 allocations and 10 unique assets per request are enforced. If allocations are successfully created, any relevant pending subaccount transactions are updated to reflect them. **Impact**: Enables programmatic creation of allocations between subaccounts. **Example**: ```json theme={null} { "allocations": [ { "sourceSubaccountId": "source_subaccount_id_1", "destinationSubaccountId": "destination_subaccount_id_1", "assetType": "BTC", "amount": "1.5" }, { "sourceSubaccountId": "source_subaccount_id_2", "destinationSubaccountId": "destination_subaccount_id_2", "assetType": "ETH", "amount": "10" } ] } ``` ## Improved Withdrawal Requests with Trusted Destination AML Support **Improved**: The withdrawal request endpoint now references Trusted Destination AML information directly, reducing the need to resubmit duplicate AML data, and adds support for Wealth Management subaccount withdrawals. **Category**: Transactions **Endpoint Changed**: * `POST /transactions/withdrawal`: `beneficiary` and `destination` AML fields are now fully optional (not deprecated). A new optional boolean field, `useTrustedDestinationAml` (default `false`), lets the caller indicate the system should use the associated Trusted Destination's AML information instead of resubmitting it. A new `SUBACCOUNT` source type is supported, with originator information auto-populated for Wealth Management clients. For joint accounts, `source.customerId` is now mandatory, and the AML questionnaire's `purpose` field is now required. **Impact**: This is a non-breaking change — `useTrustedDestinationAml` defaults to `false`, preserving prior behavior. No action is required unless you want to use the new field, in which case update your Withdrawal payload to set `useTrustedDestinationAml: true` and omit redundant Beneficiary/Destination AML data. This affects Withdrawal API and Wealth Management integrations. **Example**: *Standard custody withdrawal to a Trusted Destination (originator `MY_ORGANIZATION`):* ```json theme={null} POST /v2/transactions/withdrawal { "source": { "id": "4521431f758f18cab818ea4461a01ed7", "type": "VAULT" }, "assetType": "ETH", "destination": { "id": "0x3F431f6259d8bCAa0695153bd141aF7265d086cd", "type": "ADDRESS" }, "amount": "1", "description": "", "withdrawalAmlQuestionnaire": { "useTrustedDestinationAml": true, "purpose": "REBALANCE", "originatorType": "MY_ORGANIZATION" } } ``` *Wealth Management withdrawal (`sourceType` = `SUBACCOUNT`):* ```json theme={null} POST /v2/transactions/withdrawal { "source": { "id": "15bb8b12-d991-45d2-b784-c83c4449265b", "type": "SUBACCOUNT" }, "assetType": "ETH", "destination": { "id": "0x3F431f6259d8bCAa0695153bd141aF7265d086cd", "type": "ADDRESS" }, "amount": "1", "description": "", "withdrawalAmlQuestionnaire": { "useTrustedDestinationAml": true, "purpose": "REBALANCE" } } ``` ## Added Endpoint to Create Trusted Destinations **Added** the ability to create trusted destinations via the API, simplifying the process for programmatic use cases. Each request requires quorum approval. **Category**: Trusted Destinations **Endpoint Added**: * `POST /trusted_destinations`: Creates one or more trusted destination addresses (up to 10 per request). Each destination applies to a specific asset address, or to any asset on a network when `isNetworkLevel` is `true` (e.g., ETH and USDC could both be withdrawn to an ETH address); when `false`, only the specified asset can be withdrawn to that address. For Wealth Management integrations, the destination can be tied to an `owner` representing a Wealth Management `CUSTOMER`. **Impact**: This enables programmatic creation of trusted destinations for token vesting integrations and the Wealth Management crypto withdrawal flow. A new "Manage Trusted Destinations" permission group is required to create a Trusted Destination via API. No action is required — this is an optional flow. **Example**: ```json theme={null} { "idempotentId": "YOUR_GENERATED_UUID_HERE", "trustedDestinations": [ { "assetType": "ETH", "address": "0x430EF7FAB8e10dFb8B7c50c2026d0e247FEE4B8", "name": "Test Ethereum Address 3", "trustedDestinationAmlQuestionnaire": { "destinationType": "SELFHOSTED_WALLET", "selfhostedDescription": "Personal ETH wallet for testing", "selfhostedWalletOwner": "PERSON_OR_ENTITY", "recipientType": "PERSON", "recipientFirstName": "John", "recipientLastName": "Doe", "recipientFullName": "John Doe", "recipientCountry": "US", "recipientStreetAddress": "123 Main St", "recipientCity": "San Francisco", "recipientStateProvince": "CA", "recipientPostalCode": "94105" }, "description": "Test Ethereum wallet for demo purposes", "memo": "ETH demo wallet 3", "isNetworkLevel": false }, { "assetType": "ETH", "address": "0x3088D00C2CF28327DF06E53CA6D6A3b5642534bA", "name": "Test Ethereum Address 4", "trustedDestinationAmlQuestionnaire": { "destinationType": "SELFHOSTED_WALLET", "selfhostedDescription": "Organization ETH_R wallet", "selfhostedWalletOwner": "MY_ORGANIZATION", "recipientType": "MY_ORGANIZATION", "recipientFullName": "Demo Company Inc", "recipientCountry": "US", "recipientStreetAddress": "1 Market St", "recipientCity": "San Francisco", "recipientStateProvince": "CA", "recipientPostalCode": "94105" }, "description": "Test ETH", "memo": "ETH wallet", "isNetworkLevel": true } ], "owner": { "type": "CUSTOMER", "id": "7266559476aac38fc8c7c2022f93a9d1b9b618b1c9e2b4387840b595dcd374aa" } } ``` ## Added Placeholder Template Entry **Added** a placeholder endpoint; this changelog record was left as an incomplete template without finalized details. **Category**: Uncategorized **Impact**: No functional details were provided in the original record. ## Added Client Account Onboarding Endpoints and Updated KYC Requirements **Added** a new suite of endpoints to create "client accounts" (e.g., Joint, Roth, Custodial) that reference existing onboarding KYC profiles, and updated the KYC application to reduce required information. **Category**: Onboarding **Endpoints Added**: * `POST /onboarding/accounts`: Creates a new client account (e.g., `IRA`, `ROTH`, `JOINT`, `CUSTODIAL`, `INDIVIDUAL_TAXABLE`, `INSTITUTIONAL_TAXABLE`), referencing one or more existing program customers, signers, beneficiaries, and fee configurations. * `GET /onboarding/accounts/{subaccountId}`: Retrieves a client account application. * `PUT /onboarding/accounts/{subaccountId}`: Updates a client account application. * `POST /onboarding/accounts/{subaccountId}/submit`: Submits a client account application for review. **Endpoint Changed**: * `POST /onboarding/customers`: For individuals, `physicalStateUS`/`physicalStateOther` are now conditionally required based on `physicalCountry`, a new `idType` field (`GOVERNMENT_ISSUED_ID_CARD` or `PASSPORT`) determines required identity document uploads, and `initialFundingMethod`, `sourceOfWealth`, and `initialFundingWalletGroup` have been removed. For institutions, `physicalStateUS`/`physicalStateOther` are similarly conditional, new `hasDbaName`/`dbaNames` and `constitutionDocument`/`proofOfAddress` fields were added, and `legalStructure`, `customerType`, `countryOfIncorporation`, `legalRegistAddrDifPrincPlace` (and its related address fields), `initialFundingWalletGroup`, and `sourceOfWealth` have been removed. **Impact**: This reduces the information required for client and account onboarding and enables programmatic creation of client accounts such as Joint, Roth, and Custodial accounts, which reference the KYC profiles of their underlying program customers. This affects Wealth Management integration partners. **Example**: *Creating a joint account:* ```json theme={null} { "name": "{{name}}", "externalId": "{{externalId}}", "submit": true, "entries": [ { "key": "legalEntityName", "value": "SubAccount JOINT" }, { "key": "accountType", "value": "JOINT" }, { "key": "documentPreferenceAddressDefaultEmail", "value": "kevin.flynn_4@test.com" }, { "key": "programSignerGroup", "value": [ { "programSignerFirstName": "Kevin", "programSignerLastName": "Flynn_5", "programSignerEmail": "kevin.flynn_5@test.com", "termsAgreementId": "tersmAgreementId" }, { "programSignerFirstName": "Kevin", "programSignerLastName": "Flynn_6", "programSignerEmail": "kevin.flynn_6@test.com", "termsAgreementId": "tersmAgreementId" } ] }, { "key": "programCustomers", "value": [ { "programCustomerId": "{{customerId1}}", "programCustomerRole": "PRIMARY" }, { "programCustomerId": "{{customerId2}}", "programCustomerRole": "SECONDARY" } ] }, { "key": "beneficiaryGroup", "value": [ { "beneficiaryType": "SPOUSE", "beneficiaryName": "Test beneficiary", "beneficiaryAllocation": "50" }, { "beneficiaryType": "CHARITY", "beneficiaryName": "Test beneficiary 2", "beneficiaryAllocation": "50" } ] }, { "key": "fees", "value": [ { "feeType": "ADVISORY", "feeRate": "0.1" }, { "feeType": "MANAGEMENT", "feeRate": "0.25", "feeIsBillable": true } ] } ] } ``` ## Added Detailed Level Configuration to Collateral Packages Response **Added** new properties to the collateral packages response to provide more detailed information about collateral package levels and their configurations. **Category**: Collateral Management **Endpoint Changed**: * `GET /collateral_management/packages`: Response now includes `marginReturn`, `marginCall`, `acceleratedMarginCall`, and `critical` objects, each containing properties such as `ltv`, `action`, `returnToLtv`, `warningLtv`, and `defaultNotice`. **Impact**: Clients can now retrieve more detailed information about collateral packages and their configurations. ## Improved transactionId Parameter for Subaccount Tax Transactions **Improved**: Clarified the `transactionId` path parameter description for updating tax transactions. **Category**: Tax **Endpoint Changed**: * `PATCH /tax/transaction/{transactionId}`: Now requires the use of the ledger `transactionId` rather than the previous tax transaction `id` (the Taxbit unique identifier). **Impact**: This is a breaking change for integrations that pass the Taxbit tax transaction `id`; they must be updated to use the ledger `transactionId` instead. ## Deprecated participantId Parameter on Atlas Settlement Rejection **Deprecated**: The `participantId` query parameter is no longer required, and has been removed, from the settlement rejection endpoint. **Category**: Atlas Settlement Network **Endpoint Changed**: * `POST /atlas/settlements/{settlementId}/reject`: The `participantId` query parameter has been removed. **Impact**: The server now infers the participant ID performing the rejection from the provided API Key, rather than requiring it as an explicit parameter. ## Added InvalidPrice Reject Reason to Trading Orders **Added** `InvalidPrice` as a new possible enum value for the `rejectReason` property. **Category**: Trading Orders **Endpoint Changed**: * `POST /trading/order`: `rejectReason` now includes `InvalidPrice`, providing a more specific reason for order rejection when the provided price is invalid. **Impact**: Orders can now be rejected with the `InvalidPrice` reason, giving clearer feedback for invalid-price rejections. ## Improved Subaccount Transaction Balances Structure **Improved**: The `amounts` field in subaccount transaction responses now includes a `balances` array listing supported balance types for each asset and transaction, replacing the previous `hold`, `pending`, and `posted` properties. **Category**: Subaccounts **Endpoints Changed**: * `GET /subaccounts/transactions`: `amounts.balances` array replaces `hold`/`pending`/`posted` properties. * `GET /subaccounts/transactions/{transactionsIds}`: `amounts.balances` array replaces `hold`/`pending`/`posted` properties. **Impact**: The response structure for these endpoints is now more flexible and informative, providing a clearer breakdown of balance types. **Example**: ```json theme={null} { "transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d", "subaccounts": [ { "subaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf", "amounts": [ { "assetType": "BTC", "balances": [ { "amount": "1000.00", "balanceType": "POSTED" }, { "amount": "500.00", "balanceType": "HOLD" } ] } ] } ] } ``` ## Improved Tax Forms Endpoint with Customer-Based Lookup **Improved**: Updated parameters for retrieving tax forms to use a customer identifier instead of an affiliate identifier. **Category**: Tax **Endpoint Changed**: * `GET /tax/clients/{customerId}/forms`: Path changed from `/tax/clients/{affiliateId}/forms`; the `affiliateId` path parameter was removed and replaced with `customerId`. **Impact**: This is a breaking change. Integrations must be updated to use `customerId` instead of `affiliateId` when retrieving tax forms. **Example**: ```bash theme={null} curl --request GET \ --url https://api.anchorage-staging.com/v2/tax/clients/{customerId}/forms \ --header 'accept: application/json' ``` ## Deprecated Destination and Beneficiary AML Fields for Transfers **Deprecated**: The `Destination` and `Beneficiary` fields within the transfer AML questionnaire, since Anchorage now pulls this data directly from the associated Trusted Destination. **Category**: Transfers **Endpoint Changed**: * `POST /transfers`: Within `transferAmlQuestionnaire`, the following `Destination` fields are deprecated: `destinationType`, `institutionName`, `institutionCountry`, `selfhostedDescription`. The following `Beneficiary` fields are deprecated: `recipientType`, `recipientFirstName`, `recipientLastName`, `recipientFullName`, `recipientCountry`, `recipientStreetAddress`, `recipientCity`, `recipientStateProvince`, `recipientPostalCode`. **Impact**: Given this deprecation, only `purpose` and `originator` information need be sent in `transferAmlQuestionnaire`; `Destination` and `Beneficiary` information will now come directly from the AML answers associated with the respective trusted destination. **Example**: ```python theme={null} def create_external_transfer_with_aml( amount, asset_type, sending_vault_id, externalAddress, aml_withdrawal_purpose, aml_originator_type, aml_originator_name="", aml_originator_country="", aml_originator_street_address="", aml_originator_postal_code="", aml_originator_city="", aml_originator_state_province="", transfer_memo="", ): print_header("Creating external transfer...") # purpose aml_responses={"purpose": aml_withdrawal_purpose.upper()} # originator aml_responses["originatorType"] = aml_originator_type.upper() if aml_originator_type.upper() == "MY_CLIENT": aml_responses["originatorName"] = aml_originator_name aml_responses["originatorCountry"] = aml_originator_country aml_responses["originatorStreetAddress"] = aml_originator_street_address aml_responses["originatorPostalCode"] = aml_originator_postal_code aml_responses["originatorCity"] = aml_originator_city aml_responses["originatorStateProvince"] = aml_originator_state_province idempotent_id = uuid.uuid4().hex transfer_params = { "source": {"id": sending_vault_id, "type": "VAULT"}, "destination": {"id": externalAddress, "type": "ADDRESS"}, "assetType": asset_type, "amount": amount, "transferMemo": transfer_memo, "idempotentId": idempotent_id, "transferAmlQuestionnaire": aml_responses, } ``` ## Added Asset-Specific Parameters for Transfers **Added** new asset-specific parameter objects to the transfer request body for providing on-chain tags or memos required by certain networks. **Category**: Transfers **Endpoint Changed**: * `POST /transfers`: Request body now accepts `assetParametersXRP` (`destinationTag` integer, for XRP transfers), `assetParametersXLM` (`memo` string, for XLM transfers), `assetParametersATOM` (`memo` string, for ATOM transfers — now deprecated in favor of `assetParametersCosmos`), `assetParametersCosmos` (`memo` string, for Cosmos blockchain transfers), and `assetParametersExtra` (`value` string, for other asset transfers). **Impact**: This allows you to provide the additional on-chain tags or memos required to correctly identify the recipient for XRP, XLM, ATOM, Cosmos-based, and other asset transfers. ## Improved Tax Transactions with Detailed Asset Breakdown **Improved**: Added `receivedAsset`, `sentAsset`, and `feeAsset` array properties to tax transaction responses for more detailed asset information. **Category**: Tax **Endpoint Changed**: * `GET /tax/transactions/{subaccountId}`: Response now includes `receivedAsset` (objects with `assetType`, `costBasis`, `quantity` for deposits/trades), `sentAsset` (similar, for withdrawals/sales), and `feeAsset` (transaction fee detail) arrays. The existing `received`, `sent`, and `fee` fields remain unchanged. **Impact**: This enhances the granularity of tax transaction data returned by the API, allowing for more comprehensive reporting and analysis, without affecting existing fields. ## Improved Tax Endpoint Date Formatting and Added Cost Basis Date **Improved**: Standardized date-time formatting for tax transaction and cost basis fields, and added a new cost basis date field. **Category**: Tax **Endpoints Changed**: * `GET /tax/transactions/{subaccountId}`: `transactionTime` now uses a consistent ISO-8601 date-time format. * `GET /tax/gains/costbasis/{subaccountId}`: Added a new `costBasisDate` field (ISO-8601 format); `saleDate` now uses a consistent ISO-8601 date-time format. **Impact**: Date fields across these tax endpoints are now consistently formatted, and the cost basis date is now available directly in the response. ## Improved Subaccount Withdrawals with Intermediary Bank Support **Improved**: Subaccount withdrawal endpoints now support additional bank information fields, including an intermediary financial institution. **Category**: Subaccounts **Endpoints Changed**: * `POST /subaccounts/{subaccountId}/fiat/withdrawals`: Request body adds `financialInstitution` and `intermediateFinancialInstitution` objects (each with nested `address`, `name`, `id`, and `code` — enum `ABA`, `BIC`, `DDA`); `bankAccountNr` and `bankRoutingNr` moved inside `beneficiary`; added `accountNumber` within `beneficiary` and `country` within `beneficiary.address`. * `GET /subaccounts/{subaccountId}/fiat/withdrawals/{transactionId}`: Response `customerDetails` object now reflects the updated request body fields. **Impact**: This adds the ability to specify an intermediary financial institution, which allows withdrawals to international banks that require one in addition to the depositing bank. Not all international withdrawals require an intermediary institution. ## Added Gas Station Support for Atlas Settlements **Added** the ability to use the Anchorage Digital Gas Station to cover network fees for Atlas settlements (ETH only). **Category**: Atlas Settlement Network **Endpoints Changed**: * `POST /atlas/settlements/{settlementId}/accept`: Request body now accepts a `useGasStation` boolean to have Gas Station cover fees for the acceptor. * `POST /atlas/settlements`: Request body now accepts a `useGasStation` boolean to have Gas Station cover fees for the proposer. * `GET /atlas/settlements`: Response `data.proposerSide` now includes `gasStationEnabled` (boolean, nullable if the caller lacks access to this information). * `GET /atlas/settlements/{settlementId}`: Response `settlement.proposerSide` now includes `gasStationEnabled` (boolean, nullable if the caller lacks access to this information). **Impact**: Proposers and acceptors can now request that Gas Station cover their ETH network fees, and can see whether Gas Station is enabled for a given participant on a settlement. ## Improved Subaccount Transactions with Batch Creation **Improved**: The subaccount transaction endpoint now accepts an array of transactions in a single request, enabling atomic creation of multiple subaccount transactions. **Category**: Subaccounts **Endpoint Changed**: * `POST /subaccounts/transactions`: Request body now accepts a `transactions` array of `CreateSubaccountTransaction` objects (each with `sourceSubaccountId`, `destinationSubaccountId`, `assetType`, `amount`, optional `transactionMemo`, and `idempotentId`), replacing the previous top-level fields of the same names. The `200 OK` response now returns a `transactionIds` array of `{transactionId, idempotentId}` objects instead of a single `transactionId`. **Impact**: This is a breaking change. Clients must update their integration to send a `transactions` array rather than top-level transaction fields, and to read `transactionIds` from the response instead of a single `transactionId`. This enables atomic creation of multiple subaccount transactions in one call, reducing the number of API calls required. **Example**: *Request:* ```json theme={null} { "transactions": [ { "sourceSubaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf", "destinationSubaccountId": "3eeaf765-0df2-49c9-9e1f-db9cf3e796dd", "assetType": "BTC", "amount": "1000.00", "transactionMemo": "Transaction 1", "idempotentId": "id1" }, { "sourceSubaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf", "destinationSubaccountId": "3eeaf765-0df2-49c9-9e1f-db9cf3e796dd", "assetType": "ETH", "amount": "500.00", "transactionMemo": "Transaction 2", "idempotentId": "id2" } ] } ``` *Response:* ```json theme={null} { "data": { "transactionIds": [ { "transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d", "idempotentId": "id1" }, { "transactionId": "d5d6763e-1c18-4d4e-a4f9-966cbe18886e", "idempotentId": "id2" } ] } } ``` ## Added Tax Form Endpoints for Accounts and Subaccounts **Added** new endpoints to retrieve generated tax forms for affiliates and subaccounts. **Category**: Tax **Endpoints Added**: * `GET /tax/clients/{affiliateId}/forms`: Retrieves an affiliate's generated tax forms. * `GET /tax/subaccounts/{subaccountId}/forms`: Retrieves a subaccount's generated tax forms. **Impact**: Allows retrieval of affiliate and subaccount tax forms. ## Improved Tax Transaction Cost Basis Updates with Structured Lots **Improved**: The tax transaction update endpoint now accepts a structured JSON payload supporting multiple tax lots. **Category**: Tax **Endpoint Changed**: * `PATCH /tax/transaction/{transactionId}`: Request body content type changed to `application/json`; added optional `data` property containing nested `assetType` (string) and `lots` (array of objects with `acquisitionDatetime`, `quantity`, and `cost`). **Impact**: Allows updating cost basis information for tax transactions using a structured JSON payload with support for multiple tax lots, providing a more robust and organized way to manage tax-related transaction data. **Example**: ```json theme={null} { "assetType": "BTC", "lots": [ { "acquisitionDatetime": "2024-01-15T12:00:00Z", "quantity": "1.0", "cost": "20000" }, { "acquisitionDatetime": "2024-02-20T15:30:00Z", "quantity": "0.5", "cost": "11000" } ], "type": "DEPOSIT", "acquisitionDatetime": "2024-03-05T09:45:00Z" } ``` ## Added Manual Billing Charges API for Wealth Management **Added** new endpoints to create and cancel manual billing charges. **Category**: Subaccounts **Endpoints Added**: * `POST /subaccounts/billing/charges`: Creates manual billing charges (request body includes `idempotentId`, `interval`, `feeType`, and `charges`). * `DELETE /subaccounts/billing/charges/{chargeId}`: Cancels a manual billing charge by its `chargeId`. **Impact**: Enables creating and canceling manual billing charges. ## Improved Deposit Attributions with Date Filtering and New Fields **Improved**: Added new query parameters to filter deposit attributions by date, and new fields to the response with blockchain and asset details. **Category**: Deposit Attribution **Endpoint Changed**: * `GET /deposit-attributions/attributions`: Added `attributedAtStartDateTime` and `attributedAtEndDateTime` query parameters to filter by attribution date; response now includes `blockchainTxId` and `assetType` fields. **Impact**: Users can now filter deposit attributions by attribution date, and fetch the blockchain transaction ID and asset type associated with each attribution. ## Related topics - [API Changelog](/knowledge-base/porto/api-reference/changelog.md) - [Changelog](/knowledge-base/porto/changelog.md) - [Managing rules and policies](/knowledge-base/porto/policies/managing-rules.md)