List the user's financial transactions in a date window, newest first, across all account types (bank, deposit, line of credit, investment). Each row is lean by default: id, date, amount (negative = money out), currency, booked, payee, description (omitted when it duplicates payee), an account {id, name, institution} ref, and — when available — mcc, category, and bank_details (raw provider metadata: transaction/purpose codes, currency-exchange info, and the MCC category text that banks put in additional_information — useful for categorising spend when enrichment is off). Pass "verbose": true for the full, raw transaction record.

Internal transfers: a row that moves money between two of the user's own accounts carries a counterparty {financial_account_id, transaction_id, pairing_status} object (PENDING, PAIRED or EXPIRED) naming the account on the other side and, once paired, the matching row there. Treat PAIRED rows as transfers, not spending or income, and do not count both sides. Rows without the object are ordinary. When the user did not share the other account with you, the object carries only pairing_status: still a transfer, and its other side is not in your data. A PAIRED row whose transaction_id is null has a matching row the user's rules hide from you; it is still a transfer.

Manual loan rows (accounts with category LOAN) carry entry_type: PAYMENT (debt reduced, positive, paired with the bank payment that caused it), INTEREST and FEE (debt increased, negative, generated by Synci with origin MODEL), ADJUSTMENT (a user-verified correction), OPENING (the balance when the loan was added; not a cash flow) and SCHEDULED_PAYMENT (posted on a schedule when no bank account pays the loan). Count a loan payment once: either the bank row or the PAYMENT row, not both.

Manual bank accounts (integrator MANUAL, category BANK) are filled from statement files the user imports; their rows carry origin IMPORT and an import_batch_id, and are otherwise ordinary bank rows.

Investment rows also carry: type (raw activity, e.g. BUY / SELL / DIVIDEND / CRYPTO_SEND), is_cash_flow, units, and price_per_unit (the effective per-unit price in this row's currency, = |amount| / units). IMPORTANT for "what did I spend": rows with is_cash_flow=false are asset transfers or income-in-kind (crypto send/receive, staking, stock splits) — NOT money spent; exclude them from spending totals. Use amount, units and price_per_unit for trade figures; ignore any price written into the description string (it is the provider's own and can be in a different currency).

Dates: "date" is Synci's per-account authoritative date by default (what the user sees; "spending in June" means this). Override with date_field "booking" or "value" to filter/sort/show a specific date instead. Both booked and pending transactions are returned by default; filter with status ("all" | "booked" | "pending", default "all"). Pending amounts can still change.

Coverage: meta.earliest_available_date is the date the queried accounts are synced from. If it is later than your "from", the window is only PARTIALLY covered — data before it was never synced (not absent), so any total would silently under-report. Caveat the coverage, or narrow "from" to it.

Pagination: results are bounded by the date window and "limit" (default 50, max 100). Check meta.has_more: if true, request the next page by passing meta.next_cursor as "cursor" (keyset paging, no gaps or overlap). A page may hold fewer rows than "limit" (the user can exclude transactions from outbound channels), so never read a short page as the end of the data; only has_more=false is. Sensitive identifiers (IBAN, account numbers, etc.) are always omitted, and an IBAN the bank wrote into payee, description or other transaction text is replaced with "[hidden: account number]".