Developers
Move money across ACH, wire, SEPA, and RTP through a single, predictable REST API. Every write is idempotency-keyed and signed, every state change emits a webhook, and a full sandbox lets you simulate rails before you touch real funds.
Quickstart
curl https://api.latchpay.xyz/v1/payouts \ -H "Authorization: Bearer $LATCHPAY_KEY" \ -H "Idempotency-Key: run_8fa2" \ -d '{ "currency": "USD", "rail": "auto", // ACH · wire · SEPA · RTP "items": 412, "reconcile": true }'
{
"type": "payout.settled",
"run": "run_8fa2",
"rail": "rtp",
"settled": 412,
"returned": 0
}
Built for builders
Resource-oriented, idempotency-keyed, HMAC-signed requests with scoped API keys. No surprises, no replay risk.
Typed SDKs for Node, Python, Go, and Ruby, generated from the same spec that powers the API reference.
Every state change — created, sent, settled, returned — arrives as a signed event you can verify and replay.
Idempotency keys make every write safe to retry. Duplicate runs are impossible, even across timeouts.
Simulate every rail, force returns and delays, and run test payouts before a single real cent moves.
Pull a fully reconciled ledger via API, or stream events straight into your warehouse.
Six resources cover the whole settlement lifecycle. Everything else is a webhook.
POST /v1/payouts creates a run of one or a million items; GET /v1/runs/:id tracks it through created → sent → settled, with per-item states and partial-failure semantics — one bad payout never blocks a run.
POST /v1/recipients validates account and routing details up front and screens every recipient against sanctions lists before any rail is touched. Onboard via API or a hosted flow.
GET /v1/balances shows your segregated 1:1 balance per currency; POST /v1/funding prefunds a run or arms just-in-time debits from your operating account.
GET /v1/ledger returns the immutable, line-level record — every disbursement matched to its return, fee, and bank statement line. Export as CSV or JSON, or stream it into your warehouse.
POST /v1/webhook_endpoints registers a signed destination. Events: payout.created, payout.sent, payout.settled, payout.returned, run.completed, status.changed.
POST /v1/sandbox/simulate forces the scenarios you need to handle before go-live: an R01 return, a rail outage with failover, a delayed settlement window. Test keys never touch a real rail.
Reference notes
Conventional HTTP codes with a machine-readable body: error.code, error.message, and the offending param on validation failures. 4xx means fix the request, 5xx means retry idempotently — never re-key.
600 reads and 120 writes per minute per key by default, with Retry-After on 429. Batch endpoints count one request per call, not per item — a million-payout run is one write.
Every write requires an Idempotency-Key; same key within 24h returns the original response. The API version is pinned in the path (/v1); within a version, changes are additive only.
Request access to get sandbox keys, the full API reference, and an engineer to help you ship your first settlement run.