List PIX transactions
Lists the transactions this plugin has persisted, most recent first. Use it to reconcile your own records against the plugin’s, or to find the local transaction id of an order you know only by its end-to-end id.
Read-only. Every filter is optional and they combine with AND: account_id (the Midaz alias the row carries: the payer’s ledger account on a payment, the credited one on a cash-in, the debited one on a refund), end_to_end_id, status (the eTransactionStatus NAME, e.g. EXECUTED), and is_refund. is_refund is tri-state and parsed leniently — only “true” and “false” filter, and ANY other value (including “1” or “yes”) leaves the filter unset rather than erroring, so a typo there silently widens the result set. There is no pagination and no page size: the response is the whole matching set in one array, so filter narrowly on a busy account. Amounts are integer centavos.
An unknown account_id or end_to_end_id is not an error — it matches nothing and returns an empty array, so absence here means “nothing persisted under that value”, never “the value is wrong”. The only refusal is 400 PIX-0061 for a status that is not a known eTransactionStatus name.
THIS FEED INCLUDES MOVEMENTS THAT BELONG TO INDIRECT PARTICIPANTS, and nothing here separates them. When this participant serves indirect participants (institutions registered with POST /v1/indirects), their credits and payments are persisted as ordinary transactions and come back mixed in with the direct participant’s own. Name the institution to separate them: indirectId lists only one indirect’s transactions, and ispb only one direct participant’s books (its indirects included). GET /v1/indirects//transactions remains the purpose-built feed for reconciling an indirect (it is windowed, cursor-paged and ordered for reconciliation, which this one is not).
A token confined to one participant or one indirect has to name it in ispb or indirectId; the listing then holds only what that one holds, and naming another is refused before anything is read. Naming neither lists every participant’s transactions, exactly as before. Refusals: 422 PIX-0128 for an ispb this deployment does not act as; 400 for an indirectId that is not a UUID or an ispb that is not 8 digits.
Authorizations
JWT bearer token issued by the identity provider.
Query Parameters
Filter by the Midaz alias the row carries (the debited account on a refund, @pi_{ispb} for an indirect).
"@pagador"
Filter by the SPI end-to-end id.
"E1234567890"
Filter by eTransactionStatus name.
"EXECUTED"
Filter by refund flag ('true'/'false').
"false"
The ISPB of the direct participant whose transactions are listed. OPTIONAL: omit it and the listing is not narrowed by participant, exactly as before. Named, only transactions booked in that participant's books come back - which includes those of the indirect participants it serves. An ISPB this deployment does not act as is 422 PIX-0128. It is ROUTING DATA you supply: it narrows what comes back and never widens what your token can reach, and a token confined to one participant has to name it here. Sending it empty (ispb=) reads the same as omitting it.
^[0-9]{8}$"12345678"
The registered indirect participant (UUID) whose transactions are listed. OPTIONAL: omit it and the listing is not narrowed by indirect. Named, only transactions recorded for that indirect come back - never the direct participant's own. A token confined to one indirect has to name it here.
"3f2504e0-4f89-41d3-9a0c-0305e82c3301"
Response
OK
The list of transactions.

