> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.bridge.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Changelog
## **Multichain and Multicurrency Liquidation Addresses (Beta)**
Liquidation Addresses now support multichain and multicurrency configurations, letting your customers use a single deposit address for multiple assets and/or multiple EVM chains.
* Set `chain` to `evm` to generate an address usable across any supported EVM chain (e.g. Ethereum, Polygon, Base, Tempo).
* Set `currency` to `all_supported` to accept any currency Bridge supports on the given chain(s).
These two options are independent and can be combined. This feature is in beta — [read the integration guide](/platform/orchestration/liquidation_address/multi-chain-currency) to learn more.
## **FedNow offramps beta launch ⚡**
Bridge now supports instant, 24/7/365 USD offramps to FedNow-eligible accounts, using the FedNow payment rail. Combined with FedNow onramps (already live), Bridge now supports instant USD settlement in both directions. We're currently in a beta phase so that we can build the best product possible before we make it generally available (GA). If you're interested in joining, please [sign up for our waitlist](https://forms.gle/oabPCu6UMucjYWCv8) and we'll reach out as soon as we can onboard you. Pricing is \$0.50 per transfer for existing developers and \$1.00 for new developers. For more information and to start integrating, refer to our [USD integration guide](/get-started/guides/move-money/usd-integration-guide#fednow-).
## **USDT on Tempo and USDC on XDC support in Orchestration APIs**
We've added support for USDT on Tempo (`usdt.tempo`) and USDC on XDC (`usdc.xdc`) in our Orchestration APIs.
## **Webhook behavior improvement**
Starting 06/29, we're making a small improvement to how reactivated webhook endpoints behave. Previously, when a developer reactivated a webhook endpoint that had been deactivated, Bridge would replay all the webhooks that had queued up during the deactivation period. This could create bottlenecks and throughput issues. Going forward, reactivating a webhook endpoint will only deliver webhooks from that point onward—no backlog replay. This makes the behavior more intuitive and avoids the throughput problems. If you would like to replay webhooks, you can list upcoming webhook events and resend events.
## **Webhook behavior improvement on reactivation**
Starting 06/29, we're making a small improvement to how reactivated webhook endpoints behave. Previously, when a developer reactivated a webhook endpoint that had been deactivated, Bridge would replay all the webhooks that had queued up during the deactivation period. This could create bottlenecks and throughput issues. Going forward, reactivating a webhook endpoint will only deliver webhooks from that point onward—no backlog replay. This makes the behavior more intuitive and avoids the throughput problems. If you would like to replay webhooks, you can [list upcoming webhook events](/api-reference/webhooks/list-upcoming-events) and [resend events](/api-reference/webhooks/send-event).
## **Issuance Rewards History API**
A new endpoint gives you visibility into daily reward accruals for your stablecoin issuance program:
* `GET /v0/rewards/{currency}/history` — paginated daily reward records across your entire program, including per-provider breakdowns, AUM, fees, and distribution status.
Data is calculated with a t-2 business day lag; the most recent available record corresponds to two business days prior to the current date. Results are paginated with a configurable page size (up to 90 days) and cursor-based pagination.
Learn more in the [Rewards API reference](/api-reference/rewards).
## **Prefunded wallet activity webhooks**
Prefunded wallets now support `bridge_wallet.activity` webhooks for balance activity. Subscribe your webhook endpoint to `bridge_wallet.activity` to track when a prefunded wallet is credited or debited using the same activity model as Bridge Wallet history.
Fiat-funded prefunded wallets may still emit `virtual_account.activity` or `static_memo.activity` webhooks for the fiat instruction lifecycle. Use `bridge_wallet.activity` for the wallet balance event.
## **Time filtering for Bridge Wallet history**
The Bridge Wallet history API now supports `starting_time` and `ending_time` query parameters, letting you retrieve wallet activity within a specific time window.
Times must be provided in ISO 8601 format. `starting_time` is inclusive and `ending_time` is exclusive. You can also combine these filters with event ID cursors to paginate within the filtered results.
Learn more in the [Bridge Wallet history API](/api-reference/bridge-wallets/get-transaction-history-for-a-bridge-wallet).
## **return\_instructions for Liquidation Addresses**
Liquidation Addresses now support a `return_instructions` field, giving you control over where Bridge sends funds when a transaction fails or is returned.
`return_instructions` accepts an `address` and an optional `memo`, replacing the deprecated `return_address` field. For Stellar addresses, a `memo` is required to route funds to the correct end-customer.
`return_instructions` and `return_address` are mutually exclusive — set one or the other, not both.
The deprecated `return_address` field continues to work for non-Stellar chains but will be removed in a future release.
## **FedNow onramps are now live ⚡️**
Your customers can now receive funds via FedNow – settling in seconds, 24/7/365 – with no integration changes required on your end.
**What this means for you**
* **Instant settlement:** Customers can fund time-sensitive actions without waiting hours or days for funds to clear
* **Better liquidity management:** Faster settlement means less capital sitting idle in prefunded accounts
**How it works**
FedNow is automatically enabled across your existing virtual accounts and transfers. As more institutions adopt FedNow (1,500+ and growing), a portion of inbound USD wire and ACH payments will begin settling instantly via FedNow. The sending institution determines which rail is used – not Bridge – and we expect this transition to happen gradually over time.
To check whether a payment arrived via FedNow or another rail, look at the `payment_received_rail` field on the Transfer source, or the `payment_rail` field on Virtual Account source data. Learn more [here](/get-started/guides/move-money/usd-integration-guide).
## **Bridge Wallet activity webhooks and history API**
Bridge Wallets now support activity webhooks and history API access.
Developers can subscribe to `bridge_wallet.activity` and use `GET /v0/customers/{customerId}/wallets/{walletId}/history` to track deposits, direct deposits, withdrawals, returns, and undeliverables in one consistent activity model.
Enable webhook delivery by creating or updating a webhook endpoint subscribed to `bridge_wallet.activity`. Learn more in the [Webhook APIs](/api-reference/webhooks/get-all-webhook-endpoints) and [Bridge Wallet history API](/api-reference/bridge-wallets/get-transaction-history-for-a-bridge-wallet).
## **New Deactivate Endpoint for External Accounts**
We've added a new `POST /v0/customers/{customer_id}/external_accounts/{id}/deactivate` endpoint that deactivates an external account while keeping it visible in list and retrieve APIs. Deactivated accounts can be reactivated later via the existing `reactivate` endpoint.
Previously, the `DELETE` endpoint was labeled as "Deactivate" in our API documentation, but it actually soft deletes the record and hides it from list and retrieve APIs. We've corrected the documentation to accurately reflect this behavior — `DELETE` is now described as deleting the external account.
If you need to temporarily disable an external account while preserving access to the record, use the new `deactivate` endpoint instead of `DELETE`.
## **USDC and usDCBL on Aptos support**
Bridge now supports USDC and usDCBL on Aptos across all orchestration products including virtual accounts and transfers. View all supported payment routes [here](/get-started/introduction/what-we-support/payment-routes).
## **Transfers now reflect the rail the payment was received on**
The rail on which Bridge actually received funds for this transfer. Populated once funds have been received.
This may differ from `payment_rail`, which reflects the rail the transfer was created with. For example, a transfer created with `payment_rail: wire` will have `payment_received_rail: ach` if the funds arrive via ACH.
## **USDC on Sui support**
Bridge now supports USDC on Sui across all orchestration products including virtual accounts and transfers. View all supported payment routes [here](/get-started/introduction/what-we-support/payment-routes).
## **Memoless Stellar deposits**
Stellar deposits now include the muxed address, `memoless_to_address`, letting customers send funds without needing to attach a memo. The existing memo-based flow remains available for wallets and exchanges that don't yet support muxed addresses. This is a non-breaking change. Please read more [here](/get-started/guides/move-money/supported-blockchains).
## **USDC on HyperEVM Support**
Bridge now supports USDC on HyperEVM across all orchestration products including virtual accounts and transfers. Available to all developers.
## **\[Beta] Support for fixed fees for Virtual Account onramps**
We’re excited to announce support for fixed fees on Virtual Account onramps, giving developers more flexibility in how they monetize on our platform. In addition to fixed fees, developers can now configure fees by rail and define minimum and maximum fee bounds.
This feature is currently available in gated beta. If you’re interested in getting access before we make this feature generally available, please contact us to join our waitlist.
Learn more about how you can monetize on our platform [here](/platform/orchestration/fees-and-mins/devfees#developer-fee-configuration-beta-feature).
## **Bridge now supports Tempo Mainnet**
All developers can now use the [Tempo blockchain](https://tempo.xyz/) across Bridge's full suite of products including onramps, offramps, wallets, virtual accounts, issuance, and cards. Tempo is purpose-built for payments at scale — with a dedicated payments lane for predictable low fees, instant settlement, and native payment features — powering agentic payment flows, global payouts, supplier payments, remittances, and more. [Read our integration guide](/get-started/guides/move-money/tempo-integration-guide) to learn more.
## **Refund Status Enhancements**
We've added two new payment states to give you better visibility into payment returns and refunds:
* `refund_in_flight` — refund is in progress
* `refund_failed` — refund attempt was unsuccessful, see the return\_reason field to see more details
These states appear in Transfers, Virtual Accounts, and Liquidation Address APIs and in the Dashboard, API responses, and webhooks. This is an additive, non-breaking update.
## **Non-Breaking Improvements to Customer Responses**
Effective 05/01/2026, we're making additive updates to the `v0/customers` endpoint and customer webhook payloads:
* A new `client_reference_id` field will be added to `v0/customers` responses and customer webhook events.
* Some `rejection_reasons` values (`developer_reason`, `reason`) may change.
Developers should ensure webhook integrations tolerate new fields and treat rejection reason strings as free-form rather than hard-coding them. This is a non-breaking update.
## **Prefunded Account API Deprecation**
As of Mar 24, 2026, Prefunded Accounts are deprecated in Bridge’s APIs. We will continue to support Prefunded APIs indefinitely, but incremental improvements will be driven through Bridge Wallets. Read more [here](/platform/wallets/prefunded_wallets).
## **Scoped API Keys**
You can now create API keys with granular, resource-level permissions — restricting access to only the resources your integration needs (customers, transfers, wallets, webhooks, etc.). Scoped keys are immutable: permissions are fixed at creation and won't automatically expand as new features ship. Create scoped keys from the API Keys page in the [Dashboard](https://dashboard.bridge.xyz).
## **GBP On/Offramps via Faster Payments — Now Generally Available**
GBP on/offramping via the UK's Faster Payment System (FPS) is now generally available. Your individual and business customers can:
* Onramp to a unique UK virtual account number from 1st party deposits and 3rd party payments from approved businesses.
* Offramp to 1st and 3rd party UK bank accounts.
Customers must have the `faster_payments` endorsement. Contact your account manager or [sales@bridge.xyz](mailto:sales@bridge.xyz) to enable. [Read the integration guide](/get-started/guides/move-money/gbp_fps_integration_guide) to learn more.
## **USDT on Solana Support**
Bridge now supports USDT on Solana across all orchestration products including virtual accounts and transfers. Available to all developers. Existing USDT pricing applies.
## **USDT On/Offramps with MXN and BRL**
Bridge now supports onramps and offramps to/from USDT using MXN (via SPEI) and BRL (via Pix) payment rails. Supported on Ethereum, Plasma, and Tron. Rates and pricing follow existing MXN/BRL terms. Requires MXN/BRL addendum and SPEI/Pix endorsements.
## **Tron Support in Custodial Wallets**
Bridge custodial wallets now support custody and on-chain management of USDT on Tron. Fees aligned with existing USDT pricing.
## **External Account Webhook Support**
We are adding support for External Account webhooks on 03/09/2026. We will be supporting `created` and `updated` webhooks.
## **Additions to ExternalAccount Fields**
We are adding the below fields to the External Account endpoints on 03/09/2026.
1. `deactivation_reason`
You can now see why an external account was deactived. Refer to the API for details at [Retrieve an External Account object](/api-reference/external-accounts/retrieve-an-external-account-object).
2. `deactivation_details`
You can now see any additional details, if available, as to why an external account was deactived. Refer to the API for details at [Retrieve an External Account object](/api-reference/external-accounts/retrieve-an-external-account-object).
*Please note this data will only appear for external accounts that were deactivated after 02/26/2026*
## **USDT on Ethereum in Custodial Wallets**
Bridge custodial wallets now support USDT on Ethereum. Available to all developers, with fees aligned with existing pricing.
## **Celo blockchain onramp & offramp support**
Bridge now supports onramps and offramps for USDC.Celo. Check out all of our supported orchestration routes [here](https://apidocs.bridge.xyz/get-started/introduction/what-we-support/payment-routes#supported-fiat-rails).
## **Enhanced crypto return support via Transfers API**
You can now set return instructions on Transfers to control where crypto deposits are refunded. If a crypto deposit associated with a Transfer needs to be returned, Bridge will send the funds to the address specified in return\_instructions.
This is a more flexible alternative to a global crypto return policy, since it lets you configure return destinations per payment—without requiring you to route funds through an omnibus wallet or "be in the flow of funds."
Learn more about crypto returns [here](/platform/orchestration/more/returns#returning-crypto-deposits).
## **Fixed Outputs — Fixed Destination Amounts in Transfers**
You can now specify a fixed destination-currency amount when creating a Transfer. Bridge automatically calculates the required source amount based on real-time exchange rates, guaranteeing your recipient receives exactly the amount you specify. Useful for payroll, bill payments, and vendor disbursements.
Supported currencies: USDC/USDB to EUR, MXN, BRL, GBP (offramps) and MXN, BRL, EUR, GBP to USDC/USDB (onramps). [Read the integration guide](/get-started/guides/move-money/fixed_outputs_integration_guide) to learn more.
## **EURC on Ethereum Support**
Bridge now supports EURC on Ethereum across all Orchestration APIs including virtual accounts and transfers. Available to all developers. Existing orchestration pricing applies.
## **USDT on Plasma Support**
Bridge now supports USDT on Plasma across all Orchestration APIs including virtual accounts and transfers. Available to all developers. Existing USDT pricing applies.
## **GBP onramps and offramps via Faster Payments (Beta)**
Bridge now supports GBP (British Pound) onramps and offramps via UK's Faster Payment System (FPS) in beta. Your individual and business customers can now:
* Onramp to a unique UK virtual account number from 1st party deposits and 3rd party payments from approved businesses (Individual 3rd party payments not supported).
* Offramp to 1st and 3rd party UK bank accounts, withdrawing funds or completing payments to individuals and businesses.
Customers must have the *faster\_payments* endorsement. For more information and to start integrating, please refer to our [GBP FPS Integration Guide](/get-started/guides/move-money/gbp_fps_integration_guide#transfer-onramp).
## **USDG (Global Dollar) on Solana Support**
Bridge now supports USDG (Global Dollar) on Solana across all Orchestration APIs including virtual accounts and transfers. USDG is a regulated stablecoin issued with support from the Global Dollar Network. Available to all developers, with existing orchestration pricing.
## 🇧🇷 **BRL onramps and offramps via Pix now available**
Create Pix virtual accounts to onramp BRL deposits from external bank accounts and receive payments from approved third parties. You can also offramp BRL to any recipient instantly with Pix payments. If you’d like to enable BRL capabilities, refer to our [integration guide](/get-started/guides/move-money/brl_pix_integration_guide).
## **🔁 Reverse Exchange Rates Now Supported**
The Exchange Rates API now supports fetching rates in both directions for all supported fiat pairs.
**Previously:** USD → EUR, USD → MXN, USD → BRL
**Now also:** EUR → USD, MXN → USD, BRL → USD You can use the same request shape — no code changes required.
## **💸 New Payment State: missing\_return\_policy**
Bridge will now mark crypto deposits with a new status — `missing_return_policy` — when a refund is required but no return policy is configured.
To resolve, [configure a return policy](/platform/orchestration/more/returns) via API or dashboard, and we’ll auto-initiate the refund to the sender’s original address.
## **New dashboard updates!**
**Account Page Enhancements**
* You can now manage **admin permissions** for your team directly from the **Account** page — no support ticket needed.
* Find a summary of **monthly invoices** under the **Billing** tab, with links to download detailed PDFs.
**Help & Onboarding Resources**
* The left nav now includes quick access to our **Help Center**.
* A detailed **Onboarding Guide** is available to help new developers create customers and send payments.
**\[Beta] New Payments Module**
* Our new payments experience is rolling out in dashboard (public beta).
* We welcome your feedback!
## **Handling Proof of Address Requests**
We will be more consistently requesting proof of address when we detect conflicting location signals in a user's KYC/KYB.
If using the API, you can tell if a customer needs to submit proof of address by looking at the endorsements section of a customer response, where the requirement will show up as missing
```json theme={null}
{
"endorsements": [
{
"name": "base",
"status": "incomplete",
"requirements": {
...
"missing": {
"all_of": [
"proof_of_address",
...
]
},
...
},
},
```
To submit a proof of address document via API, include `documents` in your customer put/post request body, with an entry where the purpose is `proof_of_address`
## **Use Your Bridge Wallet to Automate Returns**
You can now use a Bridge Wallet to **seamlessly fund fiat returns.**
Bridge’s Transfer API already lets you return ACH, Wire, or SEPA deposits in cases of recalls, rejections, or refunds. Now, you can use a Bridge Wallet to **fund those returns directly**—no need to wait for a fresh deposit to initiate a payout.
* Pre-fund your wallet at any time
* Return funds instantly when needed
* Simplify your flows
Learn more [here](/platform/orchestration/more/returns)!
## **Additions to LiquidationAddress, VirtualAccount, and StaticMemo Fields**
We have added the below fields to Bridge endpoints.
1.`customer_id` added to `LiquidationAddress`
You can now identify which customer owns a liquidation address. Refer API reference at [Get a liquidation address](/api-reference/liquidation-addresses/get-a-liquidation-address).
2. `created_at`**added to VirtualAccount and StaticMemo**
Timestamp fields are now included to help with auditing and sorting. Refer API reference at [Get a Virtual Account](/api-reference/virtual-accounts/get-a-virtual-account).
3.`source_deposit_instructions.payment_rails` added to `StaticMemo`
Includes the source details in the static memo response (supported rails right now are ACH & wire). Refer API reference at [Get a Static Memo](/api-reference/static-memos/get-a-static-memo).
4.`destination_payment_rail`**now included in history records**
The `StaticMemo` and `VirtualAccount` objects returned in history endpoints now show the `destination_payment_rail` (e.g. USD.USDC.polygon) once the payment completes successfully.
Refer API reference at [Virtual Account Activity](/api-reference/virtual-accounts/virtual-account-activity) and [Static Memo Activity](/api-reference/static-memos/static-memo-activity)