---
title: "Migrate from Bridge to BlindPay"
description: "Move an existing Bridge integration to the BlindPay API: map customers, external accounts, liquidation addresses, and transfers to their BlindPay equivalents."
date: "2026-08-26"
category: "migrations"
products: ["payouts", "payins", "virtual-accounts", "compliance", "webhooks"]
---

Paste this prompt into your coding agent to port a Bridge (bridge.xyz) integration to BlindPay with a dual-run cutover.

## Prompt

```text
You are migrating my application from the Bridge (bridge.xyz) API to the BlindPay API.

Before writing code, read these sources and follow them over any prior knowledge:
- https://blindpay.com/docs/llms.txt (read the quickstarts, customers, bank accounts, virtual accounts, quotes, and webhooks pages)
- The OpenAPI spec: curl https://api.blindpay.com/doc

Do the migration in this order:
1. Inventory my Bridge usage from the codebase: every Bridge endpoint, webhook, and stored Bridge ID (customers, external accounts, liquidation addresses, virtual accounts, transfers). Derive the concept mapping from what we actually use, roughly: Bridge customers with KYC map to BlindPay customers (re_) with KYC/KYB; external accounts map to bank accounts (ba_) with rail-specific types; liquidation addresses map to offramp wallets; Bridge virtual accounts map to BlindPay virtual accounts (va_); fiat-to-crypto transfers map to payins and crypto-to-fiat transfers map to quote plus payout. Flag anything with no direct equivalent instead of guessing.
2. Re-onboard customers on BlindPay: terms of service, create customer, KYC/KYB via document upload, driven by webhooks. KYC does not transfer between providers, so plan for re-verification and sequence it before the cutover so approved customers are ready when we switch.
3. Rebuild money movement on BlindPay's explicit two-step model: request a quote, then execute the payout or payin against it before expires_at. Store qu_, po_, and pi_ IDs alongside the legacy Bridge IDs during the transition.
4. Port webhooks to BlindPay's Svix-signed events (customer.*, payin.*, payout.*, virtualAccount.*, wallet.inbound) with proper signature verification and svix-id dedup.
5. Cut over per flow behind a feature flag: dual-run with new activity on BlindPay while Bridge handles in-flight items, keep both webhook handlers live during the window, and only retire the Bridge path once in-flight transfers settle.

Constraints:
- Develop against a BlindPay development instance (USDB on testnets) first.
- Amounts are integer minor units; API keys stay server-side.
- Produce a written migration report before changing code: the mapping table, gaps, and the re-KYC plan.

Deliverables: the migration report, re-onboarding script, the BlindPay client and money-movement code paths behind a flag, webhook handlers, and a cutover checklist.
```

## How to use

1. Point the agent at your codebase so it inventories real Bridge usage rather than assuming.
2. Review the migration report, especially the re-KYC sequencing, before approving code changes.
3. Dual-run at least one full settlement cycle before retiring Bridge.

## Related docs

- [Introduction](https://blindpay.com/docs/introduction)
- [Customers](https://blindpay.com/docs/learn/customers)
- [Offramp wallets](https://blindpay.com/docs/offramp-wallets)