List transactions
Returns a paginated list of transactions for the authenticated company, ordered by date descending.
Transactions are raw bank/credit card activity. For accounting-level detail (double-entry debits and credits), see journal entries instead.
Keeping a local copy in sync
If you need to mirror this company’s transactions and pick up changes over time,
use the updated_after parameter. It returns only transactions modified since your
last sync, including deletions, so you don’t have to refetch everything. See that
parameter for how to start and continue a sync.
For one-off questions (“what did we spend on AWS last month?”), leave out
updated_after and use the regular filters.
Authorizations
API key prefixed with finta_
Query Parameters
Maximum number of results to return (1-500). Defaults to 100.
1 <= x <= 500A cursor for pagination. Pass the next_cursor value from a previous response to fetch the next page.
Filter by approval status. If omitted, returns both approved and pending transactions.
approved, pending Filter by assigned category prefixed ID.
^cat_Filter by public transaction type.
standard, transfer, split Filter by whether the transaction has been categorized.
Case-insensitive text search on merchant name.
Case-insensitive exact match on the integration or vendor name.
Case-insensitive exact match on the source account type.
bank, credit, reimbursement Return transactions on or after this date (YYYY-MM-DD). If omitted, no lower bound.
Return transactions on or before this date (YYYY-MM-DD). If omitted, no upper bound.
Return only transactions modified after this Unix timestamp (seconds, not milliseconds), for keeping a local copy in sync without refetching everything. Supplying it changes the response in three ways: results are ordered oldest-modified first instead of by date, next_cursor becomes an opaque token rather than a transaction id, and deleted transactions are included with deleted: true so you can remove them from your copy. The response also carries a watermark — pass that value back as updated_after on your next sync rather than using your own clock. Page through until has_more is false, then store the watermark. Note this filters on when a transaction was last modified, which is unrelated to start_date/end_date, which filter on its date. Start a new mirror with updated_after=0, which matches every transaction: the initial load and every later sync then share one ordering and one cursor, and the watermark it returns joins them with no gap. Do not seed a mirror from the list without updated_after — it returns no watermark, leaving you to invent a starting point from your own clock, which is the drift this parameter exists to avoid. A sync from 0 also returns transactions deleted before you started, carrying deleted: true; you have no copy to remove, so skip them. Filters may be combined with updated_after and are applied normally, but know what you are getting. Filters match a transaction's current state, so a transaction that changes such that it no longer matches simply stops appearing — with no deleted tombstone, because it was not deleted. deleted: true is reported only for genuinely deleted transactions. If you are keeping a persistent mirror, that means your copy can only grow: rows enter correctly and never leave, and the drift is silent. Sync with updated_after alone and filter your own side. If you are answering a question rather than maintaining a copy, or filtering on something that cannot change (source_vendor, source_type), the combination is safe.
1771183600
Response
A paginated list of transactions
list The canonical path of the collection, relative to the API host. Useful for logging, debugging, and generic pagination utilities that do not need to be aware of the specific endpoint.
"/api/v1/transactions"
Whether there are more results beyond this page.
Pass this value as starting_after to fetch the next page. Null when has_more is false.
Only present when updated_after was supplied. The server-generated Unix timestamp to pass as updated_after on your next sync. It is identical on every page of one sync; store it once you receive a page with has_more false.
1771183600