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), the plugin’s own local key rows (whose status is only a hint), 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.
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, and the claims source reads only the FIRST §8.2.08 page (100 rows), so an account with more in-flight claims than that is silently short. 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 CRM account id whose keys to list.
"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"
Response
OK
The list of key entries.

