Get a PIX key claim
Reads one claim live from DICT (§8.2.15 Consultar Reivindicação). Nothing local is consulted: account_id exists only to validate the caller and to produce the ISPB §8.2.15 requires, and the plugin’s own key row is deliberately ignored because it is absent for a claim this plugin never opened and gone once the row is soft-deleted.
So this route serves the same universe as the default GET /v1/claims: any claim DICT associates with the caller’s ISPB, including one opened by another account of the same institution. Note what the response does NOT carry - only claimId, key and ispb are serialized. DICT’s situation and which side of the claim you are on are read and then dropped, so this route cannot tell you whether a claim is open, confirmed or cancelled; read state from GET /v1/claims?status=processing or GET /v1/entries instead. A claimId DICT does not know is 404 PIX-0020, and DICT being unavailable is 503 PIX-1050.
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.
Path Parameters
The claim id.
"claim-123"
Query Parameters
The CRM account id of the caller.
"acc-123"
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"

