Corridors
Coverage as live data, bank forms as schemas
More than 20 local corridors are live across LatAm and Africa, and SWIFT extends payouts to 130+ countries in total. GET /v1/corridors serves methods, live minimums, mid-market rates and arrival estimates without an API key, and every corridor ships a schema that tells your form exactly what to collect.
One registry from form to validation
Read live coverage
GET /v1/corridors returns each corridor's transfer methods, live minimum, rate, arrival estimate and status. It is public and CORS-open, so coverage pages and pre-signup flows call it straight from the browser; flag icons and currency symbols ship in the payload.
Render the bank form
GET /v1/corridors/{currency}/beneficiary_schema lists the exact fields that destination requires, with labels and validation patterns. Pix is addressed by a key and tax id, SEPA by an IBAN, mobile money by a number and provider; your integration never branches on method by hand.
Submit the beneficiary
POST /v1/customers/{id}/beneficiaries validates against the same registry entry that produced the schema, so the rendered form and the applied rules can never drift. Rejections come back per field with stable codes, and IBANs are de-spaced and names normalized before they reach the rails.
Pay out over the right rail
The corridor's transfer_methods decide how a payout travels: bank rails such as SEPA, Faster Payments, ACH, NIBSS and SPEI, instant systems such as Pix, mobile money such as M-Pesa, or wallet payouts. Where a rail demands regulatory data, the schema serves it as required select fields.
FAQ
It reflects real capability, not a static table. Minimums are live-derived where upstream fee data is available, arrival estimates are served per corridor, and a corridor's status changes when the underlying rail does. Build availability logic on GET /v1/corridors, never on a hardcoded list.
No. GET /v1/corridors, every beneficiary schema and GET /v1/jurisdictions are public and allow browser requests, so marketing pages and pre-signup flows can show live coverage before a user ever signs up.
The schema is the single source. When a destination adds or changes a field, the served schema changes, and a form rendered from it updates itself. Because submissions validate against the same registry entry that produced the schema, there is no window where your form and the platform's rules disagree.
Instant alias-based systems such as Pix, addressed by an email, phone number or tax id; mobile money such as M-Pesa and MTN MoMo, addressed by a mobile number plus provider; and wallet payouts such as GCash. SWIFT covers destinations beyond the local corridors.
Where the banking partner requires a relationship to the recipient and a purpose of transfer, today on INR, MXN, TRY, VND, AED and JPY, the beneficiary schema serves both as required select fields with the exact accepted values. Invalid values reject up front with validation_failed, before money moves.
More of the platform