List an indirect participant's transactions

Returns the movements booked on ONE indirect participant’s @pi_{ispb} account, so that participant can reconcile its own books against this ledger. Each row carries the end-to-end id, the direction, the amount, the settlement status, the instant it was booked, and both parties as captured at booking — the payee block being the indirect’s own client on a credit.

Reconcile on status, not on presence. An inbound credit is booked PENDING the moment it is claimed and turns EXECUTED once the ledger credit landed, in the same row; a row can therefore appear PENDING in one sweep and EXECUTED in the next, and a row that stays PENDING is a credit that never landed (RUNBOOK §2.6). The feed does not hide claims, because it is ordered by booking time and a status filter would drop a row that settles after its booking instant has already been swept past.

Call it whenever you need the authoritative record rather than the notice: this plugin PUSHES a message to the indirect’s delivery endpoint on every movement, and that push can die permanently (the retries are exhausted, or the endpoint answers 4xx, after which the notice is parked as INVALID and never retried). The money is booked correctly either way, so a movement whose notice failed is invisible to the indirect until it is read here. Sweeping this feed on a schedule is what closes that gap; it is also the only way to re-read a window after a local outage.

Read-only; nothing changes, and no notice is re-sent.

amount is in CENTAVOS, as an integer — 1050 is R$ 10,50. It is never a decimal, and never reais.

since is REQUIRED, as an RFC 3339 instant. The feed is always read over a bounded window: without a lower bound the query is an unbounded sweep of the money table whose answer is not reproducible between two calls, so a caller could not tell a slow response from a truncated one. The window is HALF-OPEN — since is inclusive, until is exclusive — so two adjacent sweeps neither double-count a movement nor leave one in the gap between them; passing the previous window’s until as the next window’s since is the correct way to walk forward. until is optional and, when absent, leaves the window open-ended.

Rows come back OLDEST FIRST, ordered by (occurredAt, id), and the cursor is the ONLY correct way to page. The order is stable to the row: two movements can be booked in the same instant, and without the id as a tie-break a page boundary falling between them would return one of them and drop the other silently — which for a reconciliation is worse than returning nothing. Pass the previous page’s nextCursor back as cursor; a null nextCursor means that page was the last one in the window. Do NOT try to page by advancing since past the last row’s occurredAt: that skips every other movement booked in that same instant. The cursor is opaque — its content is this service’s business and is free to change. limit defaults to 25 and is CLAMPED to 100 (a larger value is silently reduced, not rejected), so do not read the page size you asked for as the page size you got.

Optional directIspb names the direct participant the indirect is read as; a token confined to one direct participant has to name it.

Refusals: 404 PIX-0095 when no indirect with that id exists in this tenant — an id belonging to another tenant is deliberately indistinguishable from an unknown one, and no movement is ever read for it; 422 PIX-0128 when directIspb names a direct participant this deployment does not act as, before the indirect is read; 404 PIX-0147 when directIspb names a direct participant the indirect is not mounted on, and no movement is read; 422 PIX-0098 when indirectId is not a valid UUID, when since is absent or is not an RFC 3339 instant, when until is not an RFC 3339 instant or is not strictly after since, or when cursor is not a token this service issued (a cursor is refused rather than silently treated as the start of the window, which would replay settled movements as if they were new).