Returns transactions for a bank account (BANK or CREDIT type). For CREDIT (credit card) accounts, this is the ONLY way to get itemized transactions (purchases, subscriptions, etc.). Each credit card transaction MAY carry `creditCardMetadata.billId` pointing at a bill from openfinance_list_credit_card_bills, but this is a per-connector HINT, not authoritative: some connectors (e.g. Nubank) populate it sparsely (many transactions and installments arrive with no billId) or inconsistently (the same payment tagged to more than one bill). Do NOT reconstruct a bill's total by summing transactions by billId — the bill's own `totalAmount` from openfinance_list_credit_card_bills is the source of truth. CREDIT PENDING vs POSTED varies by connector: where the bank exposes future-dated `status:'PENDING'` installments, those represent the OPEN bill plus future bills (future months); where it does NOT, only the last closed bill's POSTED items appear until ~closing. Same query, different coverage per bank (upstream). To get a standardized open-bill total / total debt regardless, use openfinance_list_credit_card_bills (`open_bill` / `total_pending_debt`). Supports from/to date filters (ISO YYYY-MM-DD) and an optional keyword filter via `search_queries` (case- and accent-insensitive substring match against description and merchant name, OR semantics across multiple terms). When `search_queries` is set the tool aggregates up to 5000 transactions within from/to before filtering — narrow from/to if `truncated:true` is returned. PAGINATION: OMIT `page` (the default) to get ALL transactions in the from/to range in one call — the tool auto-paginates the upstream and returns them under a single logical page (`page:1`, `totalPages:1`), up to a 5000 ceiling (`truncated:true` + warning if exceeded, then narrow from/to). Pass an explicit `page` (with `page_size`, max 500) only if you want to walk pages manually instead. On upstream errors, returns { total:0, results:[], warning, error } instead of throwing. `detail` controls how much per-row data you get (default `'compact'` = slim, cheap). Use `detail:'rich'` to enrich each row (when the bank connector provides it) with `merchantInfo` (estabelecimento: businessName/razão social, cnpj, cnae, category — useful for auto-classifying spending) and extra `creditCardMetadata` fields: `billId` (a per-connector HINT toward the transaction's bill — sparse/inconsistent on some connectors like Nubank, so do NOT sum by it to get a bill total; use the bill's `totalAmount` instead), `purchaseDate`, `payeeMCC`, `feeType`/`feeTypeAdditionalInfo`, `otherCreditsType`/`otherCreditsAdditionalInfo`. Use `detail:'raw'` to get the FULL untouched Pluggy transaction object (everything Pluggy returns, un-normalized — heaviest, for when you need a field we don't project). 'rich'/'raw' add tokens per row and coverage varies by bank/Open Finance, so keep the default for normal listings. For the card's statement closing/due dates use openfinance_list_accounts (`creditData.balanceCloseDate` / `balanceDueDate`). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH account/bank these transactions belong to. When more than one bank is connected, ALWAYS cross-check the echo against the account you intended to query and name the bank when presenting results — never attribute one bank's transactions to another. If total is 0 for a CREDIT account, check the connection health via openfinance_get_item_status — `statusDetail.creditCards.isUpdated: false` means the credit card sync failed and a force sync (openfinance_force_sync) or reconnection may be needed. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a connected bank: transactions may come back incomplete or wrong until the provider recovers, and reconnecting does not fix it.
Bulk support: accepts account_ids for batched execution.
