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 PARTICIPANT, not for the account: account_id only resolves the caller’s ISPB, and the request body carries that ISPB and nothing else, so every claim DICT associates with the institution comes back - including claims that belong to OTHER accounts under the same ISPB. There is no filter, no paging and no local sort. Two consequences follow from the omitted fields: §8.2.13 declares that an omitted stReivindicacao defaults to situation 1 (Aguardando Resolução), so claims in other situations may not appear; and each row is only key, ispb and claimId, with no state, because DICT’s situation value cannot be projected onto this API’s status enum without losing cases.
With status=processing it answers something else entirely - the in-flight claims of §8.2.08, filtered to the caller’s own account number, projected onto the key-entry shape and returned under data instead of claims. The projected status is 5 (you are waiting for the holder), 6 (you hold the key and must decide) or 7 (the holder gave it away; conclude it). Cancelled and completed claims are dropped, and only the FIRST §8.2.08 page (100 rows) is read. 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. Sending it empty (ispb=) reads the same as omitting it.
Authorizations
JWT bearer token issued by the identity provider.
Query Parameters
The CRM account id whose claims to list.
"acc-123"
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-9]{8}$"12345678"