Skip to main content
GET
Returns one disclosure request made by your instance. Once the holder approves it, the response also carries the signed consent and the disclosure. The disclosure is a snapshot of the wallet’s register record, plus the verified proofs when the holder attached their bundle.
An approval is consent, not a current verification. A holder can approve while the identity is revoked or expired, because the root stays on the register. Check disclosure.chain.isVerified and disclosure.chain.status before acting on the answer.

What an approval proves

A RESIDENCY claim filed through a hosted ID link carries the keccak256 hash of the alpha-3 country code, which you can compare with the hash of the country you expect. A claim filed from a proof carries a leaf hash, which does not reveal the country. A bundle is checked against the wallet and the root on chain, and its parameters against the network’s trust anchors. Its batch date must fall within your instance’s maxStalenessDays from Set Operator Key, or 400 days when you set no bound. Each proof is then verified as a STARK. zk.verification.checks.signature reads verified when the manifest signature was checked against the operator key of the wallet’s KYC provider. It reads root-anchored when no such key was found, and then only the match with the on-chain root vouches for the manifest. A development instance also accepts stub bundles, which zk.verification.mode shows. A leaf marked commitmentOnly is bound to the root but was neither proved nor checked against the trust anchors. That holds even when proofLevel is ZK_PROOF, so check the flag on every leaf you rely on. Everything needed to re-check an approval comes back. The consent recovers to the wallet with any EIP-712 library, chain.registry names the contract that was read, and zk.proofs holds the proof bytes.

Path Parameters

string
required
The request id. Letters and digits only, at most 100 characters.

Response Fields

object

Error Codes