Issue VP
Build and sign a W3C Verifiable Presentation for a stored credential. The API key must belong to the credential owner (its DID must be on the mandate authorizedDIDs). Optionally pass targetVerifier in the request body — the verifier domain, e.g. “organization.com” — to bind the VP to that audience via proof.domain and a challenge nonce; omit it for an unbound VP.
Headers
Pin request, response, and webhook shapes to a specific dated API version (YYYY-MM-DD). Omit to use the version pinned to your API key (set when the key is created; new keys default to the latest version). New integrations should target the latest version.
^\d{4}-\d{2}-\d{2}$"2026-07-06"
Path Parameters
URN of the credential to present.
"urn:via:credential:550e8400-e29b-41d4-a716-446655440000"
Body
Domain or subdomain of the intended verifier (e.g. "organization.com"). When provided, the VP is bound to this audience via proof.domain and a challenge nonce.
"organization.com"
Response
Signed Verifiable Presentation and VP_CREATED receipt.
Signed W3C Verifiable Presentation (@context, type, holder, verifiableCredential, proof), exactly as returned by POST /credential/vp/:vcId — do not re-serialize or modify it.
Provide this or presentationEncoded (at least one is required; presentationEncoded overrides and is recommended, since a base64 string avoids JSON formatting changes that can break the signature).
Base64-encoded JSON of the signed Verifiable Presentation above.
Pass it back to POST /credential/verify as presentationEncoded (recommended) to avoid signature failures caused by JSON re-serialization in some HTTP clients.
"eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXX0="
VP_CREATED receipt issued for this presentation