Bridge — Guides & Use Cases

What this covers / who it's for. A durable, dated digest of Bridge's get-started/ guides (35 pages): per-currency on/off-ramp call sequences, the common-use-case recipes, travel rule, supported routes/chains/stablecoins, and the quick-start/sandbox flow. Facts reflect apidocs.bridge.xyz as fetched on 2026-09-03; re-verify via the bridge-development skill's protocol (llms.txt → matching .md page) + changelog/changelog.md before trusting a number here. Sibling to Customers & Compliance, Virtual Accounts, Liquidation & Wallets, and Transfers, Fees & External Accounts — this page is the "how do I actually move money" layer; those pages hold the object-level mechanics this page assumes.

1. Page index

All URLs are apidocs.bridge.xyz paths under get-started/, fetched 2026-09-03.

Page	URL	Covers
Welcome	get-started/introduction/overview.md	Product map: Customers, Orchestration, Wallets, Issuance, Cards
Platform overview	get-started/introduction/quick-start/overview.md	Product-by-product "use when"
Get set up with Bridge	get-started/introduction/quick-start/get-set-up-with-bridge.md	Dashboard account, API keys, scoped keys
Onboard your first customer	get-started/introduction/quick-start/create-your-first-customer.md	KYC links vs direct customer create
Create your first payment	get-started/introduction/quick-start/create-a-one-time-payment.md	First ACH→USDC transfer
Configure webhooks	get-started/introduction/quick-start/setting-up-webhooks.md	Create → implement → test → enable
Set up a sandbox environment	get-started/introduction/quick-start/setting-up-sandbox.md	Sandbox host, keys, simulation, limits
Supported blockchains and fiat rails	get-started/introduction/what-we-support/payment-routes.md	Rail/chain list + Route Explorer
Dollar access	get-started/guides/common-use-cases/dollar-access.md	Per-customer VA + wallet
Remittances	get-started/guides/common-use-cases/remittances.md	Sender VA → recipient wallet
Payroll	get-started/guides/common-use-cases/payroll.md	Employer VA + per-employee transfers
Cross-border payments	get-started/guides/common-use-cases/cross-border-payments.md	Customer wallet → supplier external account
Treasury management	get-started/guides/common-use-cases/treasury-management.md	USDB holding + vendor payouts
Onramp with virtual accounts	get-started/guides/move-money/virtualaccounts.md	Permanent per-customer deposit addresses
USD integration guide	get-started/guides/move-money/usd-integration-guide.md	ACH / Same-Day ACH / Wire / FedNow
EUR integration guide	get-started/guides/move-money/eur-integration-guide.md	SEPA via vIBAN
BRL integration guide	get-started/guides/move-money/brl_pix_integration_guide.md	Pix
GBP integration guide	get-started/guides/move-money/gbp_fps_integration_guide.md	Faster Payments (+ BACS fallback)
COP integration guide	get-started/guides/move-money/cop_integration_guide.md	Bre-B + CO bank transfer
MXN integration guide	get-started/guides/move-money/mxn-spei-integration-guide.md	SPEI via CLABE
Make recurring payments	get-started/guides/move-money/recurring.md	Static template transfers
Offramp with liquidation addresses	get-started/guides/move-money/offramp_liquidation.md	Permanent auto-draining on-chain address
FX guide: fiat to fiat	get-started/guides/move-money/fiat_to_fiat.md	"Stablecoin sandwich"
USDT Self Serve Trading Endpoints	get-started/guides/move-money/usdt-self-serve-trading-endpoints.md	Fixed-rate USDT trade execution
Fixed outputs integration guide	get-started/guides/move-money/fixed_outputs_integration_guide.md	Fixed destination.amount + buffer
Custodial wallets	get-started/guides/wallets/overview.md	Bridge-managed stablecoin wallets
Send fiat deposits to your wallet	get-started/guides/wallets/onramp.md	VA → bridge_wallet_id destination
Send wallet funds to a crypto address	get-started/guides/wallets/crypto-to-crypto.md	source.payment_rail: bridge_wallet → chain
Send wallet funds to a fiat external account	get-started/guides/wallets/offramp.md	Wallet → external_account_id
Cards overview	get-started/guides/cards/overview.md	Visa cards spending stablecoin balances
Spend wallet balances using a card	get-started/guides/cards/spend.md	Fund → card_accounts → transaction webhooks
Supported Blockchains	get-started/guides/move-money/supported-blockchains.md	payment_rail = chain; memo requirements
Tempo integration guide	get-started/guides/move-money/tempo-integration-guide.md	Full product support on Tempo
Crypto Travel Rule Guide	get-started/guides/move-money/crypto-travel-rule.md	When TR data is required + shape
FAQ (Travel Rule)	get-started/guides/move-money/crypto-travel-rule-faq.md	Originator/beneficiary rules, attestation, enforcement

2. The four-primitive composition

Every guide on this page — quick-start, per-currency, and every common use case — composes the same four objects. Nothing on get-started/ introduces a fifth:

1. Customer (+ endorsements) — created via POST /v0/kyc_links (hosted) or POST /v0/customers (direct); endorsements are per-rail approvals (e.g. sepa, pix, faster_payments) requested implicitly by using a rail and gated on KYC + ToS acceptance. See Customers & Compliance for the object-level detail.
2. Bridge wallet — POST /v0/customers/{id}/wallets {chain}, keyed by bridge_wallet_id (never the raw on-chain address).
3. Virtual Account — a permanent, customer-specific fiat deposit address (POST /v0/customers/{id}/virtual_accounts), the fiat-in primitive.
4. Transfer (or External Account / Liquidation Address) — the fiat-out or ad-hoc movement primitive; a Transfer's source/destination pair references any combination of a bank rail, a chain address, or bridge_wallet.

Every use case in §10 differs only in who owns which object (sender vs. recipient wallet, employer vs. employee wallets, customer vs. supplier external account) — not in a new primitive.

payment_rail overloading. The payment_rail field is reused across three unrelated vocabularies: a fiat rail (ach_push, wire, sepa, spei, pix, faster_payments, bre_b, co_bank_transfer, fednow), a chain (ethereum, solana, base, tempo, …), or the literal string bridge_wallet (source/destination is a Bridge-custodied wallet rather than an external rail). The same field name means three different things depending on position (source.payment_rail vs destination.payment_rail) and value shape — there is no separate "kind" discriminator on the wire.

payment_received_rail vs. intent. On a Transfer, source.payment_rail / destination.payment_rail are the requested rail; the rail that actually cleared is reported back as payment_received_rail (Transfers) or payment_rail on the VA source object (Virtual Accounts) — e.g. a wire destination request can still be reported with a different payment_received_rail if Bridge routed it differently. Treat the intent field as advisory and the received field as the reconciliation truth.

Implications for Stables: the D118 BridgeRailsProvider and the domain-alignment design (docs/superpowers/specs/2026-09-03-bridge-domain-alignment-design.md §4) already model this — the neutral source/destination vocabulary ({kind: 'wallet'|'address'|'bank', …}) exists specifically to collapse the payment_rail overload into one discriminated union before it reaches domain code, and client_reference_id prefixing (pay_/ord_/cst_) is how a single transfer.* webhook handler routes to the right mirror despite the shared vocabulary. Persist payment_received_rail (not just the requested rail) on every transfer mirror row.

3. Per-currency guides

Each currency below is sales-gated and requires its own endorsement before VA/external-account creation succeeds — see Customers & Compliance §6 for endorsement machine codes.

USD — ACH / Same-Day ACH / Wire / FedNow

• Call sequence. Onramp: VA with payment_rails: [ach_push, wire] (FedNow deposits also land on the same VA), or a Transfer with source.payment_rail: ach_push | ach_same_day | wire → crypto destination; response awaiting_funds + deposit instructions. Offramp: Transfer source: bridge_wallet (or crypto) → destination.payment_rail: ach | ach_same_day | wire | fednow + external_account_id. External account creation (POST /v0/customers/{id}/external_accounts, currency: usd) returns payment_rails.supported — only send fednow if it's in that list.
• States/identifiers. ach_reference (offramp, ≤10 chars, [A-Za-z0-9 ]), trace_number (15-digit), description, sender_name, sender_bank_routing_number; wire adds wire_message (≤140 chars, 4×35 Fedwire lines), imad, originator_name/address, bank_beneficiary_name/address; FedNow adds end_to_end_id, transaction_id, payment_received_rail: fednow.
• Limits. FedNow ≤$10,000,000 per onramp (network limit), 24/7/365, seconds-latency, 1st+3rd party both directions; offramps are beta/invite-only. 3rd-party VA deposits allowed for 1st party, payroll, registered business, same-surname family, and P2P <$4,000 — not supported in New York or Texas. Same-Day ACH must be submitted before cutoff (cutoff times: separate orchestration/more/cutoffs page, not in this fetch set). FedNow offramp precondition: fees must be disclosed to end users, and refunds must be configured before go-live — a rejected FedNow offramp has no return path otherwise.

Implications for Stables: D118's go-live preconditions (alignment design §6) list "crypto return policy configured before ANY crypto-in flow" — the FedNow refund-config rule is the fiat-rail analogue, gated by the same human-approval step (D118 §Go-live).

EUR — SEPA (Instant / Credit)

• Call sequence. Onramp: EUR vIBAN VA (payment_rail: sepa; source_deposit_instructions carry iban, bic, account holder = a Bridge entity) or a Transfer with source: {currency: eur, payment_rail: sepa} → e.g. USDC on tempo. Offramp: Transfer bridge_wallet USDC → {currency: eur, payment_rail: sepa, external_account_id}; the page mentions memo support without naming the field.
• States/identifiers/limits. External account: currency: eur, account_type: iban, iban.account_number. No explicit min/max stated; 1st + 3rd-party onramp and offramp supported (3rd-party onramp from individuals requires the account manager); the SEPA IBAN country list spans 44 EU/EEA + UK/Switzerland/Andorra-type territories.

Implications for Stables: every EUR leg is in-scope for the EEA no-threshold travel-rule rule (§9) with no floor — unlike USD's $3,000 threshold, a EUR-rail path cannot skip travel rule on amount alone.

BRL — Pix

• Call sequence. Onramp: BRL VA (BR code, pix; no static-amount BR codes) or Transfer pay-in. Offramp: Transfer or liquidation address → Pix external account (Pix key; EVP keys lowercase). BRL VAs cannot be offramp destinations.
• States/timing. ~5 minutes typical, up to 30 minutes for transfers over $50k.
• Limits. $500,000 USD-equivalent per customer per month; raising it requires enhanced KYB (formation docs, UBO >25% or top-4, financial-capacity/volume proof). Transfers over 5,000,000 BRL may trigger fraud-review questions. 1st + 3rd party payouts; 1st-party payins, 3rd-party payins from businesses only. Non-Brazilian individuals: offramp only; businesses: both directions.
• Endorsement change (2026-06-15). The Pix endorsement gained new requirements that day (a separate BRL migration guide, not in this fetch set — see Customers & Compliance §7 for the related pix_onramp/ pix_offramp endorsement split).

Implications for Stables: the $500k/month cap needs an independent adapter-side counter (Bridge rejects over-cap transfers, but a pre-flight check saves a round trip); the 2026-06-15 split means any BRL grant must re-check endorsement status, not assume a pre-existing pix endorsement still covers both directions.

GBP — Faster Payments (+ BACS fallback)

• Call sequence. Onramp: GBP VA (account_number, sort_code, faster_payments) or Transfer source: {currency: gbp, payment_rail: faster_payments} → e.g. USDC on base. Offramp: Transfer bridge_wallet → {currency: gbp, payment_rail: faster_payments, external_account_id}.
• States/identifiers/threshold. External account: currency: gbp, account_type: gb, sort_code, account_number. FPS ~5 minutes, up to 30 minutes for large values. Onramp min £2.00; offramp min 3.00 of source currency; no max — but transfers over £1,000,000 automatically route via BACS instead of FPS, with a 3-business-day SLA. 1st + 3rd party payouts; 1st-party payins, 3rd-party payins from businesses.

Implications for Stables: the £1M BACS fallback is a silent SLA change with no separate rail selection on the caller's part — a handler polling for "processed" on an FPS timeline must also tolerate the 3-day BACS timeline once the threshold is crossed, or surface the rail switch to ops.

COP — Bre-B + CO bank transfer

• Call sequence. Onramp: COP VA (Bre-B key, beta) or Transfer source.payment_rail: bre_b | co_bank_transfer. Offramp: Transfer → external account account_type: bre_b (bre_b_key) or co_bank_transfer (account_number, account_type: savings / account_type_detail).
• States/threshold. Onramp shows awaiting_funds; offramp shows payment_submitted. ~3 minutes typical, up to 30 minutes for larger amounts. Onramp min 100 COP; offramp min 4,000 COP; no stated max — Bre-B transfers over 11,552,000 COP are automatically sent as a bank transfer instead (same fast-rail-to-slow-rail fallback pattern as GBP's BACS threshold, just a different rail pair). 1st + 3rd party payouts; 1st-party payins, 3rd-party payins from businesses.

Implications for Stables: same handling as the GBP threshold above — treat the Bre-B→bank-transfer downgrade as an expected branch, not an error.

MXN — SPEI

• Call sequence. Onramp: MXN VA (CLABE, spei) or Transfer source: {currency: mxn, payment_rail: spei} → e.g. USDC on base. Offramp: Transfer bridge_wallet → {currency: mxn, payment_rail: spei, external_account_id, spei_reference} (spei_reference ≤40 chars, alphanumeric + spaces).
• States/identifiers/limits. External account: currency: mxn, account_type: clabe, clabe.account_number, address state (e.g. CMX/CDMX). SPEI runs 24/7, settles in seconds. Refer to the Route Explorer (§10) for current minimums; no stated max. 1st + 3rd party payins and payouts — the simplest LATAM rail here, with no 3rd-party restriction list like BRL/GBP/COP.

Implications for Stables: CLABE is the sole identifier (no separate routing/account-number pair like USD) — an adapter's neutral bank destination shape (alignment design §4) needs a CLABE-shaped variant, not a generic account-number field.

4. Recurring / static template transfers

POST /v0/transfers with static_template: true creates a reusable, shared-instructions template (e.g. sepa → polygon) that stays awaiting_funds and never expires; each matching deposit spawns a new, ordinary Transfer instance (dedupe on the instance id, not the template id), processed automatically with its own webhook. Omitting amount sets flexible_amount: true; PUT/Update changes future behavior only; list instances via GET /v0/transfers?template_id=.... Unlike a Virtual Account (customer-specific), a template's deposit instructions are shared across whoever deposits to them — the memo is the sole matching key.

Implications for Stables: if Stables adopts static templates for a funding surface, the client_reference_id prefixing scheme (§2, alignment design §4) should key on instance id, not template id.

5. Fiat-to-fiat FX ("stablecoin sandwich")

One-time setup: POST .../wallets (USDC) → USD VA with destination.payment_rail: bridge_wallet

• bridge_wallet_id → MXN CLABE external account. Per payment: POST /v0/transfers source: bridge_wallet → destination.payment_rail: spei; FX executes at market rate (not locked — see Fixed outputs below for a locked-rate alternative). Bridge's own danger note: use a static return address for the USDC leg and avoid refund_to_sender, which returns funds to an omnibus wallet rather than back to the sender. Webhook states named on the page: payment_initiated, payment_processed, cancelled. An alternative path chains VA → liquidation address → external bank account for auto-conversion on deposit.

Implications for Stables: the return-address warning is a hard operational rule, not a suggestion — any stablecoin-sandwich flow must set an explicit static return address per transfer; the default risks funds landing in an omnibus wallet Stables cannot individually attribute.

6. Fixed outputs

POST /v0/transfers with destination.amount fixed: Bridge computes source.amount plus a 1% buffer (any excess becomes a Developer Exchange Fee credited to a "Fixed Outputs Excess Funds" Bridge wallet) — or the caller supplies both source.amount and destination.amount from GET /v0/exchange_rates?from=&to= (mid-market, sell, and buy rates including fees). Supported pairs: USDC/USDB/USDT ↔ EUR, MXN, BRL, GBP, COP, USDT. Source can be a Bridge wallet or an external customer wallet. States: pending → payment_processed; if the market rate moves past the 1% buffer the transfer goes underfunded, returning additional funding instructions (payment_rail: bridge_transfer) — the top-up Transfer must use the same on_behalf_of, and any orchestration source can supply it. Bridge fails early if the initial source.amount is insufficient. receipt.exchange_rate reports destination/original-source and ignores top-ups.

Implications for Stables: behaves like a limit order, not a market order — an adapter using fixed outputs needs an underfunded handler with a funding path, and must account for the "Fixed Outputs Excess Funds" wallet as a real balance, not a rounding artifact.

7. Offramp via liquidation addresses

Sequence: create an external account (or Plaid-linked account) → POST /v0/customers/{id}/liquidation_addresses (chain + currency to receive on-chain; destination chain/currency/details; return_address for failed/returned funds) → response state: active

• a permanent on-chain address → monitor via webhook or GET .../liquidation_addresses/{la_id}/drains. Real-time rails (wire, SEPA, blockchains) forward instantly; batch rails (ACH) queue daily. Crypto-to-crypto liquidation addresses are also supported. Drain state: in_review (auto-clears; Bridge contacts after 24h if not), funds_received, payment_submitted, payment_processed (metadata may include tx_hash, imad, trace_number), undeliverable, returned, refunded, error, canceled (AML/EFE or below minimum). Forward-only — a liquidation address never holds a balance itself.

Implications for Stables: a liquidation address is the one primitive open to unknown/unlisted senders, which is exactly the "unidentifiable originator" case the travel-rule FAQ (§9) calls out — persisting return_address and treating each drain as the ledger unit (not the address) is a direct requirement, not an optimization.

8. Common use cases

All five recipes on get-started/guides/common-use-cases/ share one skeleton: API key → POST /v0/kyc_links (returns tos_link + kyc_link, described as "<1 minute", auto-updating) → POST .../wallets → POST .../virtual_accounts (USD/EUR/MXN/BRL/GBP tabs shown; samples use USDC on Ethereum as the destination) → share source_deposit_instructions. Differentiation is purely object ownership per §2.

• Dollar access — one VA + one wallet per customer; optional card: POST .../card_accounts (currency: usdb, funding type: bridge_wallet) → GET .../card_accounts/{id} (status: active).
• Remittances — VA belongs to the sender, wallet belongs to the recipient. Silent on any FX or local-payout step — as written, the flow ends at stablecoin in the recipient's wallet.
• Payroll — employer wallet + VA, one wallet per employee, one POST /v0/transfers bridge_wallet → employee wallet per employee; no batch-payout call is shown.
• Cross-border payments — customer wallet + VA + supplier external_accounts (US bank / SEPA IBAN / MXN CLABE); per payment, Transfer bridge_wallet USDB → {payment_rail: ach, currency: usd, external_account_id}.
• Treasury management — USDB (1:1 USD, yield shared with the developer) held via VA; vendor external accounts; Transfer USDB → ACH per vendor payment.

Implications for Stables: none of these five recipes need anything beyond the four primitives in §2 — the D118 adapter's capability surface should cover all five without new interfaces; D117's activity-declaration gate is the layer deciding which use case a tenant may route to Bridge for.

9. Travel rule + FAQ

Scope. Applies only to on-chain legs leaving or entering Bridge custody — not to fiat-only transfers, Bridge-wallet-to-Bridge-wallet moves, fiat-to-Bridge-wallet (no disbursement), or wallet-to-fiat-bank transfers (only the beneficiary name if not the customer).

Thresholds. EEA-related legs: no threshold, all transactions — triggered if the developer is an EEA CASP, OR the leg is EUR/EURC, OR the customer is EEA-registered. **US-related legs:

$3,000** — triggered if the developer is a US MSB/VASP, OR the leg is USD/USDC, OR the customer is US-based. An unregulated, non-EEA/non-US customer with no USD/EUR leg is not required to submit. Wallet-ownership attestation: only for EEA, self_custodied/hosted customer wallets, only above €1,000 (single or linked series) — never for Bridge wallets, third parties, or fiat legs; proof is a signature challenge, micro-deposit, or vendor tool, timestamped in the past (wallet_attested_ownership_at).

Data shape. One travel_rule_data object everywhere: originator/beneficiary, each either is_self: true (pulled from the Bridge customer profile) or explicit name, address, identifying_information (individuals) / legal_entity_identifier (businesses — VAT/EIN/reg no./LEI); plus wallet_type: external | self_custodied | hosted and, where required, wallet_attested_ownership_at.

Submission timing — on the resource vs. after the fact. Submit on create/update of the transfer, virtual account, or liquidation address when the counterparty is stable (self-to-self, treasury, a fixed known counterparty). Submit one-off via POST /v0/travel_rule_data/{id} (a transfer id, VA-event id, wallet-event id, or drain id) when the counterparty varies or is only known after the event — e.g. an inbound liquidation-address deposit from an unlisted sender. Submitting for every movement, even when not strictly required, is explicitly permitted.

Roles. Originator = the actual sender — a third party if identifiable (name + address, no attestation needed). Beneficiary of a fiat offramp = the ultimate bank-account holder. For a crypto payout to a third party: originator is_self, beneficiary carries third-party details. For an unidentifiable liquidation-address sender: submit what's known, document the model with Bridge, who resolves risk-based (named specifically for the >€1,000 case).

Enforcement — Bridge never holds funds for missing data. Bridge does not hold/freeze at the time of movement for missing travel-rule data; it reaches out to the developer (never the end customer) after the fact, escalating only after that outreach.

Implications for Stables: the alignment design (§6) already treats travel rule as a go-live precondition (EEA no threshold, US >$3,000, submitting for everything explicitly allowed). Because enforcement is after the fact, a Stables-side "submit always" policy is simplest and never penalized — but event-id capture (submitting against a webhook event id, not just at creation) must exist for VA/liquidation-address inbound flows where the counterparty is only known post-hoc.

10. Supported routes / chains / stablecoins (names only, as listed)

• Fiat rails: ACH (USD), FedNow (USD), Wire (USD), SEPA (EUR), SPEI (MXN), Pix (BRL), Faster Payments (GBP), Bre-B & Bank Transfer (COP) — "and more coming soon" per the page.
• Chains: Aptos, Arbitrum, Avalanche C-Chain, Base, Celo, Ethereum, HyperEVM, Linea, Monad, Optimism, Plasma, Polygon, Solana, Stellar, Sui, Tempo, Tron, World Chain, XDC.
• Stablecoins/assets: USDC, USDT, USDB, EURC, PYUSD, USDP, USDG, PATHUSD, CASH, USDSUI, USDCBL. Fiat currencies: USD, EUR, MXN, BRL, GBP, COP.
• Route Explorer source keys (non-chain sources): ACH, ACH Same Day, FedNow, Wire, SEPA, SPEI, Pix, Faster Payments, Bre-B & Bank Transfer, Bridge Wallet — plus crypto sources of the shape <asset>@<chain> and <asset>@Bridge Wallet.
• EEA restriction: USDC and EURC are the only stablecoins supported for EEA users, page-stated as a hard restriction (not merely a default).
• Chain-specific fields: blockchain_memo is optional on destination for Stellar, Tron, and Tempo; Stellar deposits require either the memo (returned in the deposit instructions) or the memoless_address (a muxed M-address). Tempo requires payment_rail: tempo everywhere it appears; cards on Tempo are work-in-progress.
• Warning: deposits to unsupported asset/chain pairs, or to the wrong address, may be permanently lost.

Implications for Stables: the EEA USDC/EURC-only restriction is a hard filter the neutral adapter surface (§2/§4) needs to enforce before a transfer even reaches Bridge — not something to discover from a Bridge 4xx. Cross-reference the Provider landscape chain-coverage columns against this list when either changes.

11. Quick-start + sandbox

Quick-start sequence. Dashboard account (sales-gated) → API key (shown once; revoke + regenerate on compromise) → POST /v0/kyc_links (type: individual|business, returns tos_link + kyc_link) or POST /v0/customers directly → poll GET /v0/customers/{id} for endorsement status: approved|incomplete → POST /v0/transfers → register a webhook endpoint (created disabled) → test/send-event/check logs → enable. Scoped API keys: POST /v0/api_keys (needs an unrestricted key or the api_key:create scope), name ≤100 chars, value returned once, ≤500 keys per developer; GET /v0/api_keys/whoami introspects scopes.

Sandbox is schema-only. Base host https://api.sandbox.bridge.xyz, keys prefixed sk-test, admin-only account creation. Customers can only be created via the API in sandbox (no hosted KYC links) — approve them with POST /v0/customers/{id}/simulate_kyc_approval. Explicitly no real money movement, no Plaid, no testnet settlement, and no payment webhooks; virtual accounts, memos, liquidation addresses, and transfers all return dummy data. Wallets are the one thing testable end-to-end via simulate_deposit. Developer accounts are isolated per user; rate limits are arbitrary; stablecoin issuance is production-only. Bridge's own recommendation: use sandbox only for schema testing.

Implications for Stables: the alignment design (§6) states this plainly as a go-live blocker — "money-path behaviour and the webhook signature scheme … can only be validated against PRODUCTION; plan a production canary tenant before the flip." This page corroborates why: sandbox cannot exercise a single money-moving call, a single payment webhook, or a single KYC-link flow — only object CRUD and wallet balance simulation. Any pre-go-live test plan for D118 has to budget for a production canary, not a sandbox soak.

12. Bridge doc inconsistencies / gaps

• BRL minimum conflict. The Pix page states both "minimum 10 BRL, no max" and, elsewhere on the same page, "onramp minimum 20 BRL / offramp minimum 20 BRL" — the two figures directly contradict each other and the page gives no resolution (§3, BRL).
• GBP sample shows the wrong currency. The GBP Virtual Account response sample in the integration guide has "currency": "brl" in its deposit-instructions block — almost certainly a copy-paste error from the BRL guide; do not rely on that sample's currency field (§3, GBP).
• COP field-name typo. One offramp sample on the COP integration guide spells the account type co_bank_trasnfer (transposed letters) instead of co_bank_transfer — treat the correctly-spelled form as authoritative unless a live 422 says otherwise (§3, COP).
• Generic webhook event-type list. The "Configure webhooks" quick-start page's "common event types" list (customer.created, payment.succeeded, subscription.*) reads as boilerplate, not Bridge's actual event vocabulary — the real event names live on the platform webhooks docs (see Webhooks, API Mechanics & Issuance), not here.

13. Open questions for Bridge

Consolidated + tracked in flow-alignment.md §Open questions; this section keeps this page's own detail.

• What is the actual BRL Pix minimum — 10 BRL or 20 BRL — for onramp and for offramp respectively? The integration guide states both (§12).
• What field name is correct for the COP offramp bank-transfer account type — co_bank_transfer or the page's co_bank_trasnfer? (§12)
• Does the GBP VA response sample's "currency": "brl" indicate an actual platform bug in how GBP VA deposit instructions are generated, or purely a documentation copy error? (§12)
• Cutoff times for Same-Day ACH and other batch rails are referenced but not included in this fetch set (orchestration/more/cutoffs.md) — what are the exact cutoff windows per rail?
• Is there a batch-payout endpoint for payroll-style fan-out, or is one POST /v0/transfers per employee (as shown) the only supported pattern at scale?
• Does the remittances use case actually support any FX/local-payout leg, or does Bridge consider "stablecoin lands in the recipient's wallet" the complete product surface for that use case?
• What resolves the fixed vs. flexible SEPA memo field name the EUR guide alludes to but never names?

14. Fetched 2026-09-03

Every get-started/ page in the current llms.txt index — all 35 returned HTTP 200 as raw .md under https://apidocs.bridge.xyz/; full paths are the URL column of the page index table in §1 (one row per page, same order as fetched). Two pages referenced by these guides but outside get-started/ — orchestration/more/cutoffs.md (rail cutoff times) and the BRL migration guide under platform/customers/customers/ — were not fetched for this page; see Customers & Compliance and the open questions in §13.

---

← Bridge cluster index · ← Engineering wiki