List transactions
Returns a paginated list of the caller’s transactions. Filter by type, status, customer, asset, chain, transaction hash, external payment reference, linked order, creation timestamp, or settlement timestamp (completedAfter/completedBefore). Sorted by createdAt desc by default; use sortBy and sortOrder to override, including sortBy=completedAt to order by settlement date.
Authorizations
Query Parameters
Opaque cursor from a previous response to fetch the next page
Maximum number of results to return (1-100)
1 <= x <= 100Pagination direction relative to the cursor
forward, backward deposit, onramp, offramp, withdrawal, conversion, fiat_conversion, deposit_return pending, processing, completed, failed, cancelled USD, EUR, GBP, CHF, JPY, CAD, AUD, NZD, SGD, HKD, CNY, KRW, INR, BRL, MXN, ARS, CLP, COP, PEN, ZAR, NGN, KES, GHS, EGP, AED, SAR, ILS, TRY, PLN, CZK, HUF, SEK, NOK, DKK, THB, IDR, MYR, PHP, VND, TWD, USDC, USDT, DAI, EURC, PYUSD, BTC, ETH, SOL, TRX, XLM ethereum, base, solana, polygon, tron, stellar The on-chain transaction hash or signature. Case does not matter where the chain encodes it as hex; on a chain whose encoding is case-sensitive (for example Solana), it is matched exactly, since a different case is a different value.
The provider-side reference on a fiat transaction: the sending bank's reference on a deposit, the payout provider's on a withdrawal. Both are matched, so pair it with type=deposit if you only want deposits. It is also the reference the sandbox fiat deposit simulator acknowledges with. Crypto deposits never match — resolve those with txHash, even if you passed an externalReference to the crypto simulator. Not a Conduit id, and not your own clientReferenceId.
Client-supplied reference, unique per resource within your organization. 1-255 characters from A-Za-z, 0-9, underscore, hyphen, colon, and period — no spaces.
Inclusive lower bound on completedAt, the settlement date — the date a transaction actually cleared, not when it was created. Unlike createdAfter/createdBefore, a transaction only matches once it has settled: a still-pending transaction has no completedAt and never matches this filter, on either bound. Paired with completedBefore the range is half-open [completedAfter, completedBefore), so adjacent periods (e.g. consecutive statement months) never double-count a transaction that settles exactly on the boundary.
Exclusive upper bound on completedAt — see completedAfter.
completedAt orders by settlement date and, like the completedAfter/completedBefore filters, excludes any transaction that hasn't settled yet — a still-pending row has no completedAt to sort by.
createdAt, updatedAt, completedAt asc, desc