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 still change. |
posted | Fully settled. |
reversed | Previously posted transaction that was reversed. |
cancelled | Pending item that was voided before settlement. |
unknown | The bank provided a state that does not yet map cleanly to a richer public status. |
pending and posted; the remaining values are reserved for broader coverage.
Two ways to read transactions
Historical browse — GET /v1/transactions
Use this endpoint for backfills, date-range queries, and reconciliation views. It supports filtering by accountId, connectionId, status, rail, postedDateGte, and postedDateLt. Results are cursor-paginated and can be sorted by postedDate or updatedAt.
List cursors are valid only for the same query and sort order. They are not interchangeable with sync cursors.
Incremental sync — GET /v1/transactions/sync
Use this endpoint to maintain a current mirror of transactions over time. The sync stream returns change events ordered by the server’s sync cursor ascending, not by postedDate or raw updatedAt.
No-gap bootstrap
- Call
GET /v1/transactions/sync without a cursor.
- Save the returned
nextCursor as your stream head.
- Backfill historical data from
GET /v1/transactions.
- Resume polling
GET /v1/transactions/sync from the saved cursor.
- If
hasMore is true, call again immediately with the returned nextCursor.
Duplicates between the backfill and later sync pages are expected. Reconcile by stable transaction.id.
Persist nextCursor only after the full page has been durably applied. If a sync call is retried, reuse the same cursor.
Sync event types
| Event type | How to handle it |
|---|
added | Upsert the embedded transaction by transaction.id. |
modified | Upsert the embedded transaction by transaction.id. |
removed | Delete the referenced transaction id from your current mirror. |
removed currently represents transaction deletions. Account visibility changes without transaction mutations are intentionally out of scope for the current sync stream.
Cursor and retry rules
- Sync cursors are valid only for the same stream-defining filters:
accountId and connectionId.
- Sparse
fields= selections do not change stream membership and are not part of cursor compatibility.
- Sync cursors expire after 90 days.
invalid_cursor means the cursor is malformed or does not match the filter set.cursor_expired means you need to rebootstrap from scratch.- If rate limited, honor
Retry-After when present and retry with the same cursor.
Key fields and rails
amount — Signed decimal string. Positive = inflow, negative = outflow.entryType — credit or debit, as reported by the bank.rail — Payment rail such as internalTransfer, card, ach, sepaCredit, sepaDebit, wire, swift, fasterPayments, check, cash, crypto, other, or unknown.paymentReference — Remittance reference for reconciliation (e.g. invoice number).bankReference — Bank-assigned operational tracking ID.counterpartyName / counterpartyAccountMasked — Available on many rail types.
Waycore can notify you through the transactions.sync_available webhook when fresh data is ready, so you do not need to poll blindly. Treat that webhook as a prompt to call GET /v1/transactions/sync, not as a replacement for the sync stream itself.
Endpoints
Required scopes
| Scope | Used by |
|---|
transactions:read | List, sync, get |
