Infinite (infinite.net) provides real bank accounts, payments, and compliance for global money movement through one API. This page is the map: the objects every integration is built from, how money moves through them, and the contract the platform keeps in production. The full API reference, typed SDKs, and sandbox keys are shared when you start onboarding.
Four steps cover the platform end to end. Each one is a handful of API calls; all of them ride the same objects described below.
Every business you serve is onboarded through Infinite’s compliance program — KYB, sanctions and watchlist screening, and ongoing monitoring — before any account is issued. Onboarding runs in your brand or headless via API, and a customer vetted once is vetted for the whole network.
Hosted FlowsA verified customer can hold all three account types: a Managed Account with its own account and routing numbers at Infinite’s partner banks, a yield-bearing Deposit Account, and a bank-owned stablecoin Wallet Account. You create, fund, and pay from each the same way.
Infinite AccountsOne payment instruction covers every rail. You state the amount, currency, and destination; Transfer Routes selects and executes across ACH, Fedwire, RTP, SWIFT wires, stablecoins, and FX based on destination, urgency, and cost.
Transfer RoutesEvery movement is written to a double-entry ledger and reported as a signed event, so your systems always know what moved and why. Compliance reviews progress through explicit, auditable states, and every approve or reject decision is made by a human.
Infinite AgentsEverything on the network is built from a small set of resources. Learn them once and every endpoint reads the same way — across accounts, payments, and compliance.
The root of everything you build on Infinite (infinite.net). An organization represents your business: it holds your API keys, team members, environments, and every resource you create.
Every API request is scoped to a single organization. Sandbox and production are separate environments under the same organization, with separate keys and separate data.
A business your organization serves. Customers are onboarded through Infinite’s compliance program — KYB, sanctions screening, and ongoing monitoring — before any account is issued.
A customer vetted once is vetted for the whole network. Accounts, payments, and compliance reviews all reference the customer they belong to.
Accounts hold funds and are always issued to a customer. Three types share the same API surface — create, fund, and pay from each the same way:
An instruction to move money. A payment states the amount, currency, source account, and destination; Infinite selects and executes the rail — ACH, Fedwire, RTP, SWIFT wire, stablecoin, or FX — based on destination, urgency, and cost.
Payments are asynchronous. Each one reports its status transitions over webhooks, from created through processing to settled or returned.
The executed movement of funds between two accounts. Every payment resolves to one or more transfers, and every transfer is written to the ledger.
Transfers are immutable once settled. Corrections are new transfers, never edits — the record of what moved, when, and why is permanent.
Every account is backed by a double-entry ledger. Each transfer produces balanced debit and credit entries, so the network always reconciles to zero.
Accounts expose two balances: available — funds spendable right now — and pending — funds in flight, awaiting settlement or compliance review.
Compliance is a first-class resource, not a black box. Reviews — onboarding, counterparty screening, and transaction monitoring — move through explicit states you can query and subscribe to:
Every state change is timestamped, attributed, and auditable. Every approve or reject decision is made by a human.
How the platform behaves once real money moves. The mechanics behind each promise — headers, payloads, endpoints — live in the full API reference, shared during onboarding.
Sandbox and production are separate environments with separate keys and separate data. Sandbox behaves like production, so what you test is what ships.
Every write supports idempotency keys, so an operation runs once no matter how many times a dropped connection makes you resend it.
Payments, transfers, and compliance reviews report every state change as a signed webhook event, with automatic retries when your endpoint is unavailable.
Conventional HTTP status codes, machine-readable error bodies, and a traceable request id on every response.
Your integration is pinned to the API version it launched on. Additive changes ship continuously; breaking changes never ship silently.
Start with a conversation: an engineer maps the platform to your flow of funds, and the full API reference, typed SDKs, and sandbox keys are shared when you begin onboarding. The objects every integration is built from are covered in the core concepts on this page.
One payment call covers every rail. You state the amount and destination, and routing across ACH, Fedwire, RTP, SWIFT wires, stablecoins, and FX is handled by the network — specify a rail explicitly, or let Transfer Routes pick the fastest compliant path for each payment.
Yes. Sandbox and production are separate environments with separate API keys and separate data — nothing crosses between them — and sandbox keys behave like production, so screening behavior, error handling, and reconciliation can be tested before anything goes live. The rest of the operational contract holds the same way in both.
A payment is the instruction — amount, currency, source, destination — and Infinite selects and executes the rail. A transfer is the executed movement of funds between two accounts: every payment resolves to one or more transfers, every transfer is written to the ledger, and settled transfers are immutable — corrections are new transfers, never edits.
As a first-class resource, not a black box. Screen a counterparty before funds move; reviews progress through explicit, auditable states you can query and subscribe to, and every approve or reject decision is made by a human. A counterparty vetted once is vetted for the whole network, so most checks return in seconds.
Yes — every write supports idempotency keys, so an operation runs once no matter how many times you retry it, and each state change is delivered as a signed webhook event with automatic retries when your endpoint is unavailable. The exact mechanics are part of the API reference shared during onboarding.
Walk through your architecture with the engineers who built the platform — before you write a line of code.