Change a PIX transaction limit
Changes the amount of ONE existing limit row. The row is addressed by its natural key rather than by an id: accountId, plus periodType (DAILY, NIGHTLY or MONTHLY, case-insensitive) and limitType (TRANSACTION or PERIOD, case-insensitive); transactionType is always PIX. amount is the new cap in centavos and must be greater than zero.
It is update-only. It never creates a row, and no other endpoint does either - the four default rows appear only after POST /v1/transactions first runs the limit check for the account (see GET /v1/limits). A MONTHLY row, which the service never seeds, therefore cannot be changed here.
The refusals are worth knowing before you debug one: an unknown periodType, an unknown limitType, and a well-formed tuple with no matching row ALL answer 422 PIX-0036, carrying the message about a transaction status transition not being permitted, and nothing in the response tells the three apart. A non-positive amount is the one distinct case, 422 PIX-0030 naming the amount. An accountId 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. A new cap applies from the next POST /v1/transactions; there is no scheduling and no approval window.
Which participant’s row is changed is decided by payerIspb, by exactly the rule an order’s payerIspb follows: this deployment may act as several direct participants, the accountId 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. A row of a participant you did not name is not reachable here.
Authorizations
JWT bearer token issued by the identity provider.
Body
The CRM account id whose limit to change.
"acc-123"
The new limit amount in centavos (> 0).
5000000
eTransactionLimitType name (TRANSACTION/PERIOD).
"PERIOD"
ePeriodType name (DAILY/NIGHTLY/MONTHLY).
"DAILY"
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. Send it absent, not empty; an empty string is refused 400 PIX-0061.
^[0-9]{8}$"12345678"
Response
OK
The ledger account alias the limit is kept for.
"@pagador"
The limit amount in centavos.
5000000
The limit row id.
"l1f9c0a2-..."
eTransactionLimitType name.
"PERIOD"
ePeriodType name.
"DAILY"
eTransactionType name.
"PIX"

