List PIX transaction limits
Lists the PIX limit rows that exist for the account named by account_id. Each row is a (transactionType, periodType, limitType) tuple plus an amount in centavos: periodType is DAILY, NIGHTLY or MONTHLY; limitType is TRANSACTION, the cap on a single payment, or PERIOD, the cap on everything inside the window; transactionType is always PIX.
No endpoint in this API creates a limit row. Four of them - PERIOD and TRANSACTION for DAILY and NIGHTLY, at a deployment-configured default of 30000 reais - are seeded lazily the first time POST /v1/transactions runs the limit check for the account, and a MONTHLY row is never created by the service at all. Until that first payment attempt this route answers 200 with an empty data array rather than a 404, and PATCH /v1/limits has no row to change. 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"
Response
OK
The list of transaction limits.

