A Transaction represents a single line item on a bank account as reported by the institution. Transactions are read-only and are populated automatically during connection syncs.
Status lifecycle
| Status | Meaning |
|---|
pending | Authorised but not yet settled. Amount or details may change. |
posted | Fully settled. |
reversed | Previously posted transaction that was reversed. |
cancelled | Pending item that was voided before settlement. |
Two ways to read transactions
Historical browse — GET /v1/transactions
Use this for initial backfills and date-range queries. Supports filtering by accountId, connectionId, status, rail, postedDateGte, and postedDateLt. Results are cursor-paginated and can be sorted by postedDate or updatedAt.
Incremental sync — GET /v1/transactions/sync
Use this for ongoing ETL after the initial backfill. The sync endpoint returns a changefeed of added, modified, and removed events ordered by (updatedAt, id) ascending, allowing you to maintain a local replica with minimal data transfer.
- Call once without a cursor to initialise the stream.
- Store the returned
nextCursor.
- On each subsequent call, pass the stored cursor to receive only changes since the last call.
- If
hasMore is true, call again immediately before waiting for a webhook.
A transactions.sync_available webhook is fired when new data is ready, so you don’t need to poll.
A sync cursor is only valid when reused with the same accountId / connectionId filter set.
Key fields
amount — Signed decimal string. Positive = inflow, negative = outflow.entryType — credit or debit, as reported by the bank.rail — Payment rail: ach, wire, card, sepaCredit, swift, etc.paymentReference — Remittance reference for reconciliation (e.g. invoice number).bankReference — Bank-assigned operational tracking ID.counterpartyName / counterpartyAccountMasked — Available on many rail types.
Endpoints
Required scopes
| Scope | Used by |
|---|
transactions:read | List, sync, get |
