List PIX key claims
Two different listings behind one route, selected by the status query parameter.
With no status (the default) it returns DICT’s §8.2.13 claim listing for the caller’s ACCOUNT: the request names the logged account (person type, document, branch, account type and number) and each item is kept only when it is the account’s - on a claim it opened, the item’s account is the caller’s (leading zeros not significant, and its branch, account type and holder document each compared when DICT sends it, the branch by value); on a claim it must answer as the holder, ispbDoador is the caller’s participant and dadosDoador names the caller’s account (or, when DICT omits that block, the account’s own §8.2.06 listing holds the key). A claim of another account under the same ISPB never appears. There is no paging and no local sort. §8.2.13 declares that an omitted stReivindicacao defaults to situation 1 (awaiting resolution), so claims in other situations may not appear. Each row carries key, ispb and claimId plus the optional claim facts - claimType, claimSituation (DICT’s raw stReivindicacao, not projected onto the status enum), claimSide (claimer or donor), claimerIspb, donorIspb, resolutionDeadline and conclusionDeadline.
With status=processing it answers something else entirely - the in-flight claims of §8.2.08, filtered to the caller’s account by the same rule, projected onto the key-entry shape and returned under data instead of claims, each with the same claim facts. The projected status is 5 (you are waiting for the holder), 6 (you hold the key and must decide), 7 (the holder gave it away; conclude it) or, on the donor side, 3 DONATED (you confirmed; the claimer has not concluded yet). Cancelled and completed claims are dropped, and §8.2.08 is walked across its pages up to 10 (1000 claims at 100 per page). Any other status value falls through to the default branch. An account the CRM cannot resolve is 404 PIX-2016.
Which participant’s DICT mailbox is read is decided by ispb, by exactly the rule an order’s payerIspb follows - and here it decides WHOSE claims come back, not merely which credential signs the call, because §8.2.13 and §8.2.15 answer for a PARTICIPANT. 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. When the account named on the request cannot be used by that participant, the request is refused before the operation acts and the answer names the account: 422 PIX-0137 when it is held in a ledger that is not configured for Pix, 422 PIX-0138 when its record does not say which ledger holds it, and 422 PIX-0139 when its record names a different institution. Sending it empty (ispb=) reads the same as omitting it.
Authorizations
JWT bearer token issued by the identity provider.
Query Parameters
The Midaz ledger account id whose claims to list.
"019a1b2c-3d4e-7f60-8a9b-0c1d2e3f4a5b"
Set to 'processing' to list in-flight claims as key entries instead of claims.
"processing"
The ISPB of the direct participant whose directory answers. This deployment may act as SEVERAL direct SPI participants - one ISPB each, each with its own customers and its own DICT credential - and this field is the only thing on the request that says which of them is read. 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 a transaction: never a credential, never read from a header or a path, and it never widens what your token can reach. Read the participant that holds the keys, or the listing comes back empty for an account that has them. Sending it empty (ispb=) reads the same as omitting it.
^[0-9A-Z]{8}$"12345678"