List PIX key entries
Lists the PIX keys of the account named by account_id. The response is not a table read: it is rebuilt on every call by merging three sources - the live DICT directory listing for the account (§8.2.06, every key reported as ACTIVE - a key DICT marks as under claim included, since it is still the account’s: it is listed ACTIVE with claimType and claimSide=donor), the plugin’s own local key rows (whose status is only a hint; a DONATED row is never shown, because it is the donor’s answer to a claim and not the key’s state), and the account’s in-flight DICT claims (§8.2.08), all projected onto the same eKeyStatus enum. Rows are keyed by the key VALUE: a directory key wins over a local row for the same value, and a live claim overrides both, because claim state is authoritative at DICT. A claim the account must answer as the holder (status 6, or DONATED 3 once confirmed) replaces the bare directory marker.
Each entry carries the optional claim facts when a claim is on its key - claimType, claimSituation, claimSide, claimerIspb, donorIspb, resolutionDeadline and conclusionDeadline - and omits them otherwise. Only the account’s own claims count: a claim the account opened by its own account (branch by value, account type and holder document, each compared when DICT sends it), a claim it holds as donor by ispbDoador plus dadosDoador or, without that block, by the §8.2.06 listing this same call read. Nothing is written back, so the three sources never reconcile. A local row for a key DICT no longer holds keeps appearing with its stale status until the directory or a claim overrides it, and a key that exists only at DICT appears with no claimId and no local history. There is no filter and no pagination; the claims source walks §8.2.08 across its pages up to 10 (1000 claims at 100 per page), and a walk that ends without DICT stating the last page is logged by the service rather than reported here. If any one of the three sources fails the whole request fails - the listing is never partial. account_id is required (omitting it is refused by schema validation; a blank value is 400 PIX-0061), and an account the CRM cannot resolve is 404 PIX-2016.
Which of this deployment’s direct participants answers is decided by ispb, by exactly the rule an order’s payerIspb follows: this deployment may act as several direct participants, each with its own customers and its own DICT credential, 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. 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. Read the participant that holds the keys: another one’s directory answers for its own customers, not yours.
Authorizations
JWT bearer token issued by the identity provider.
Query Parameters
The Midaz ledger account id whose keys to list.
"019a1b2c-3d4e-7f60-8a9b-0c1d2e3f4a5b"
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"
Response
OK
The list of key entries.