Returns CLOSED credit card bills for a CREDIT-type account: dueDate, totalAmount, minimumPaymentAmount, allowsInstallments, plus `payments[]` (id, paymentDate, amount, valueType, paymentMode), `payments_count`, `payments_total`, finance charges aggregates, and a derived `payment_status` per bill. IMPORTANT — Brazilian Open Finance semantics: Pluggy does NOT return a `paid`/`status` field. The payment goes into the `payments[]` of the bill whose CYCLE contains the paymentDate (closing ≈ dueDate − 7d): pre-payment before close stays on the bill being paid; payment between close and due, or after due, lands on the NEXT bill. So `payments[]` on a bill commonly carries the previous bill's payment, NOT the current one's — do NOT assume this bill was paid just because `payments[]` is non-empty. Use the derived `payment_status` (`PAID` | `OPEN` | `PAST_DUE_UNCONFIRMED` | `PAST_DUE_UNPAID`): a bill is `PAID` when its OWN `payments[]` (early pre-payment) or ANY newer bill in the payload contains a payment with amount ≈ this bill's `totalAmount` (±R$0.50). The MOST RECENT bill that's past-due, with no own pre-payment match, cannot be confirmed via cross-bill (the next cycle hasn't closed yet) — it returns `PAST_DUE_UNCONFIRMED`. NEVER call such a bill 'vencida' categorically; flag that the payment may have been made between close and due and not yet reflected upstream. The full `payment_status_legend` is returned alongside the results. OPEN BILL & TOTAL DEBT (standardized, derived — OPT-IN): pass `include_open_bill:true` to ALSO get `open_bill` (the current not-yet-closed bill, próxima a vencer) and `total_pending_debt` (saldo devedor total = all pending installments), BOTH derived from PENDING transactions so they mean the same thing across connectors — use these instead of the CREDIT account's `balance`, whose meaning VARIES by connector (some report the open-bill partial, others the full installment debt). `open_bill` = { available, method (`cycle_dates` = real close/due dates | `calendar_month_fallback` = estimated, `confidence:'low'`), close_date, due_date, total_amount (net charges − credits), transaction_count }; plus a `future_bills[]` breakdown per month — LOW-confidence forward projections of PENDING installments (`confidence:'low'`, `basis`), NOT authoritative bills (for closed months trust the `results` `totalAmount`). CONNECTOR ASYMMETRY: where the bank does NOT expose the open bill before closing (only closed bills, no reliable cycle dates), `open_bill.available` is `false` with a `reason` (`connector_exposes_no_pending` or `open_bill_not_published`) — that bill isn't retrievable by any endpoint until it closes (upstream limit of the institution's Open Finance feed, not our filter); check the bank app for the current open bill. When per-transaction billId grouping does not reconcile with the bills' totals, a `bill_grouping_reliability` warning is attached (trust `totalAmount`, do not sum by billId). Default `false` (the projection runs an extra accounts+transactions scan, so it's opt-in). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH card/bank these bills belong to. When more than one bank is connected, ALWAYS cross-check the echo against the card you intended to query and name the bank when presenting results — never attribute one bank's bills to another. This tool's `results` are bill-level summaries — NOT individual transactions, and each bill's `totalAmount` (from the bank) is the AUTHORITATIVE amount. To see itemized purchases/charges, use openfinance_list_transactions with the CREDIT account_id — but note `creditCardMetadata.billId` is a per-connector hint that can be sparse/inconsistent (e.g. Nubank), so do NOT reconstruct a bill total by summing transactions by billId. Returns a warning instead of failing if the CREDIT_CARDS product is not enabled.
Bulk support: accepts account_ids for batched execution.