Borderli API

Borderli moves money over Latin America's QR rails. You integrate once with Borderli and reach Pix in Brazil, Transferencias 3.0 in Argentina, QR Bolivia, and the interoperable QR schemes of Chile, Colombia, Peru and Uruguay. Borderli handles the local scheme, the local acquirer and the local currency account. You never touch them.

Two directions

	Pay-out	Pay-in
What happens	You pay a merchant's QR code. Your user scans a QR abroad, and the merchant is paid on their local rail, in their local currency.	You collect money. Borderli issues a QR, the payer scans it with their bank or wallet app, and the funds settle to your account.
Typical integrator	A wallet or bank app whose users travel or shop abroad	A merchant, marketplace or PSP that needs to accept local QR payments
Endpoints	`/v1/resolve`, `/v1/execute`, `/v1/pay`	`/v1/collect`, cancel, refund
Guide	Pay-outs	Pay-ins

How a payment flows

You call the API. The response is a pending transaction. This is fast, usually well under a second.
The rail settles the payment. This takes seconds on every rail we support.
Borderli sends a signed webhook to your server with the final status: completed, failed or canceled.

You can also poll GET /v1/transactions/{id} at any time. Webhooks are the normal path. Polling is the fallback.

Things that are true everywhere

Money is an integer in minor units plus a currency code. 1000 with BRL is R$10.00. See Pay-ins and the reference for field names.
Every request needs an API key in the x-api-key header. See Authentication.
Every request that moves money needs an Idempotency-Key header. Retrying with the same key never pays twice. See Idempotency.
Errors have one shape. A type you can switch on, a message you can read, and a request_id you can send to support. See Errors.
Every response carries an x-request-id header. Log it.

Where to start

Quickstart: your first pay-out and pay-in against the sandbox.
API Reference: every endpoint, field and error, grouped by direction.