ProofPack Mint API
Mint selective-disclosure proofs (ProofPacks) for delegated agent wallets
The ProofPack Mint API lets you (the human, using your API key) generate ProofPacks: selective-disclosure proofs that reveal only chosen identity fields to a specific agent wallet. You call the API and pass the agent’s wallet address in the request. That wallet must be delegated to you via an IsDelegate attestation chain (you → agent, or you → agent → sub-agent → …). The API walks the full chain back to your human root and only mints if the chain is valid—so you can mint for a direct delegate or for a sub-agent several hops deep.
For the full user journey from attested identity to a JWT with a claim like nationality, see Getting a ProofPack JWT with a Nationality Claim.
Base path: /api/v1/proofpack
Category: Zipwire Attest
Features:
Generate selective-disclosure proofs for delegated agent wallets.
Choose which identity fields to reveal (e.g. nationality, date_of_birth).
Output as JWS (JSON) or JWT (compact string).
All responses use HTTP 200; check the
successfield in the body for success or error.
Authentication
Every request must include your API key.
Header:
X-API-Key: your-api-key-hereIf the API key is missing or invalid, the response is still 200 OK with an error in the body:
{
"success": false,
"code": "InvalidApiKey",
"message": "Invalid or missing API key"
}Response format
All responses use the same shape. Use success to decide whether the call succeeded.
Success:
Error:
Some error responses include a top-level suggestions field (object) to help you fix the request. For InvalidFieldSelection, the response body includes suggestions with an available_fields array listing the valid field names for your account.
Endpoint: Mint ProofPack
POST /api/v1/proofpack/mint
Generates a ProofPack for a single delegated agent wallet.
Request body
agentWallet
string
Yes
Ethereum wallet address (0x-prefixed) that is delegated to you. Can be a direct delegate or a sub-agent multiple hops down the chain (e.g. Human → Agent1 → Agent2 → Agent3); the API walks the chain back to your human attestation.
selectedFields
string[]
No
Optional. Field keys to reveal (e.g. nationality, date_of_birth). If omitted or empty, the proof is minted with no identity fields revealed. If provided, must be a non-empty list of keys that exist in your identity data. See Available fields for keys from Yoti document verification.
format
string
No
"JWS" (JSON) or "JWT" (compact). Default: "JWS".
Validation
agentWallet: Required; must be a valid Ethereum address.
selectedFields: Optional. If omitted or empty, the proof is minted with no identity fields revealed. If provided, must be a non-empty array; each field must exist in your identity data. Field names are case-sensitive. If you request a field that doesn’t exist, the error message lists the invalid field names you sent, and suggestions.available_fields in the response lists the valid field names for your account.
Success response (200)
Example errors (all 200 OK, with body indicating failure)
Invalid API key:
Agent not delegated:
Invalid field:
The message lists the field names you requested that are not in your Merkle tree. The response includes a suggestions object with available_fields (array of valid field names for your account) so you can correct your request.
Error codes
InvalidApiKey
API key missing or invalid.
NoHumanAttestation
Your account has no identity attestation.
AgentNotDelegated
The agent wallet has no valid IsDelegate attestation to a human.
DelegationPointsToDifferentHuman
The agent is delegated to someone else, not you.
MerkleTreeNotFound
Identity data for your account could not be found.
InvalidFieldSelection
One or more requested fields don’t exist; the message lists the invalid names you sent; suggestions.available_fields lists the valid field names for your account.
ProofGenerationFailed
Proof generation failed.
InternalError
Unexpected server error.
Output formats
JWS (default)
Set "format": "JWS" or omit format. The proofPack value is a JSON object with payload and signatures (RFC 7515 JSON serialization). Use this when you need to parse or validate the full proof structure.
JWT
Set "format": "JWT". The proofPack value is a compact string: header.payload.signature. Use this when you need a short, URL-safe string (e.g. in headers or URLs).
How delegation is checked
Before minting a ProofPack, the API walks the delegation chain from the wallet you passed to your human root:
Looks up IsDelegate attestations for the agent wallet (the one in your request).
Follows refUID link by link (e.g. SubAgent → … → Agent → Human). The chain can be multiple hops deep; the verifier supports this with depth and cycle safeguards.
Verifies the chain reaches a valid human identity and that identity is the same as the owner of the API key.
If any step fails, returns the appropriate error code (e.g.
AgentNotDelegated,DelegationPointsToDifferentHuman).
So you can call the Mint API with a sub-agent’s wallet address and receive a ProofPack for that sub-agent—the API traces the full chain back to you.
Selective disclosure
Your identity data is represented in a Merkle tree. When you provide selectedFields, the ProofPack reveals only those fields; other fields are committed by hash and not exposed. If you omit selectedFields (or pass an empty array), the proof is minted with no identity fields revealed.
Available fields come from Yoti document verification (e.g. passport or driving licence). Typical keys include:
Personal:
full_name,given_names,family_name,nationality,date_of_birth,place_of_birth,genderDocument:
document_number,issuing_country,document_type,expiration_date,date_of_issue,issuing_authorityTechnical / metadata:
mrz,document_template,idsp_id,report_id,report_date_utc
Exact fields depend on your stored identity and document type. If you send an invalid field name, the error response lists the invalid fields you requested and includes suggestions.available_fields with the list of valid field names for your account.
Example request
Best practices
Minimal disclosure: Only request fields the agent actually needs.
Check
success: Always look at thesuccessfield before usingproofPackor other result fields.Handle errors: Use the
codeandmessagefields to handle invalid keys, undelegated agents, and invalid fields.Verify on the agent side: The agent should verify the ProofPack with the ProofPack library before trusting the contents.
For verification and integration patterns, see ProofPack & Agent Delegation and ProofPack Examples. For the end-to-end journey to obtain a JWT ProofPack (attestation → delegation → mint), see Getting a ProofPack JWT with a Nationality Claim.
Last updated