Get available PIX limits
Computes what is left of each limit for the account: availableAmount = totalLimit - usedAmount, floored at zero, in exact int64 centavos with no rounding. currentPeriod names the period that is active right now.
The windows are the part that surprises callers, and they are UTC calendar-day bands. DAILY is the half-open [init, end) hour range taken from the tenant’s systemplane knobs transaction_limits.daily_period_init and transaction_limits.daily_period_end (6 and 20 when unset). NIGHTLY is the WHOLE complement of that band summed across the day - both [00:00, init) and [end, 24:00), not only the band the request falls in. MONTHLY is summed over a single UTC day, NOT a month, so a MONTHLY row’s usedAmount reports today’s usage only.
usedAmount is the sum of the account’s live outbound rows of the same transaction type - CASH_OUT plus on-us INTRA_PSP - created inside the window, with NO status filter, so a pending or failed payment still counts against you; outbound refunds are included too, matching what the enforcement check counts. An account with no limit rows at all is 404 PIX-0063 (see GET /v1/limits for why that is a normal state rather than a fault), an account_id the CRM cannot resolve is 404 PIX-2016, and one the ledger holds no account for (unbound, or absent from the ledger) is 422 PIX-0108.
Whose limits these are is decided by payer_ispb, by exactly the rule an order’s payerIspb follows: this deployment may act as several direct participants, the account id is an alias that is unique only inside one of them, and naming none is answerable only while there is one answer. Omit it while this deployment acts as a single participant; once it acts as several, omitting it is 422 PIX-0127 and naming one it is not is 422 PIX-0128. Read the headroom of the SAME participant you pay as.
Authorizations
JWT bearer token issued by the identity provider.
Query Parameters
The CRM account id whose limits to read.
"acc-123"
The ISPB of the direct participant whose limits these are. This deployment may act as SEVERAL direct SPI participants — one ISPB each, each with its own books — and the account id is an alias that is unique only inside ONE of them, so this field is what says whose rows to read or write. OPTIONAL while it acts as a single participant: omit it and that one answers. REQUIRED once it acts as several — omitted is 422 PIX-0127, and an ISPB this deployment does not act as is 422 PIX-0128. It is ROUTING DATA you supply and guarantee, exactly like payerIspb on an order: never a credential, never read from a header or a path, and it never widens what your token can reach. Use the SAME participant you pay as, or the headroom you read is not the headroom that gets enforced. Sending it empty (payer_ispb=) reads the same as omitting it.
^[0-9]{8}$"12345678"

