Setup
We will setup a Verifier service inside of a tenant. If you don't have a tenant yet, you can learn how to create one here.
CURL
Endpoint: /v1/{target}/resource-api/services/create | API Reference
Example Request
curl -X 'POST' \
'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{target}/resource-api/services/create' \
-H 'accept: */*' \
-H 'Authorization: Bearer {yourToken}' \
-H 'Content-Type: application/json' \
-d '{
"type": "verifier2",
"baseUrl": "http://org.enterprise.localhost:3000",
"clientId": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiU05JZ1ItTHZzSEUtNkhUUGxYYUpQVDVubHRZMFpqZlA0VkpTWEwzQ2ZkMCIsIngiOiJIVWM1ZHY1eFREV3VMVmZQcFdvVXBWTjZ1QTNJNzBsVzVnNEhoMG5VaDQ0In0",
"clientMetadata": {
"client_name": "walt.id Enterprise Verifier",
"logo_uri": "https://cdn.walt.id/verifier/logo.png"
}
}'
Body
{
"type": "verifier2",
"baseUrl": "http://org.enterprise.localhost:3000",
"clientId": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiU05JZ1ItTHZzSEUtNkhUUGxYYUpQVDVubHRZMFpqZlA0VkpTWEwzQ2ZkMCIsIngiOiJIVWM1ZHY1eFREV3VMVmZQcFdvVXBWTjZ1QTNJNzBsVzVnNEhoMG5VaDQ0In0",
"clientMetadata": {
"client_name": "walt.id Enterprise Verifier",
"logo_uri": "https://cdn.walt.id/verifier/logo.png"
}
}
Further metadata configuration options can be found in the official specification here
Path Parameters
orgID: - When performing operations within an organization, it is essential to use the organization's Base URL or another valid host alias. For example, if your organization is namedtest, your default Base URL will betest.enterprise-sandbox.walt.devwhen using the sandbox environment.target: resourceIdentifier - The target indicates the organization + tenant in which to create the new Verifier service and the service's ID ({organizationID}.{tenantID}.[NewVerifierServiceID]), e.g.waltid.tenant1.verifier1
Body Parameters
type: serviceType - Specifies the type of service to create. In our caseverifier2baseUrl: String - This URL will be included in the generated OIDC4VC offer, allowing the wallet to know how to reach the verifier. It should reflect your organization's base URL. The general format for this URL ishttps://{orgID}.yourEnterpriseStackUrl.com. For example, if your organization is named myorg and the Enterprise Stack is hosted at the domain enterprise-stack.com, your base URL would be: https://myorg.enterprise-stack.com.clientId: String (optional) - The identifier the verifier presents to wallets during credential exchange. Supports multiple formats (defined in OID4VP 1.0, §5.9.3):- Omitted — unsigned sessions emit
redirect_uri:<response_uri>. Prefer this for unsigned OID4VP; Wallet2 does not need a pre-registered allow-list. - Plain string (e.g.
"verifier2") — Treated as OpenID4VPpre-registered. Wallet2 rejects it unless that exact id is inconfiguration.preRegisteredClientsand the session destination is in that entry'sredirect_uris. Registration plus in-bandclient_metadataisinvalid_client. - DID (e.g.
"decentralized_identifier:did:jwk:...") — A decentralized identifier that the wallet can resolve to verify the verifier's identity. Signed-only. x509_san_dns:<hostname>(e.g."x509_san_dns:verifier.example.com") — Client identity bound to the DNS name in the certificate's Subject Alternative Name extension. Wallets verify the signed request against the SAN in the provided certificate. Use together withkeyandx5corx5cReferences. Signed-only.x509_hash:<base64url-sha256-hash>— Client identity bound to the SHA-256 hash of the DER-encoded leaf certificate. Wallets verify the signed request and check that the certificate matches the hash. Use together withkeyandx5corx5cReferences. Required by the HAIP profile. Signed-only.
- Omitted — unsigned sessions emit
clientMetadata(optional): Object - Verifier metadata config. Can be used to edit e.g. externally exposed human-readable verifier name and logo. Defaults to{"client_name": "Verifier"}. Learn more in general here or expand below to see object property options.
Expand to learn more about metadata config object properties
Metadata Config Object
"metadataConfig": { "client_name": "walt.id Enterprise Verifier", "logo_uri": "https://cdn.walt.id/verifier/logo.png" }client_name(optional) String: Human-readable string name of the verifier.logo_uri(optional) String: URL string that references a logo for the verifier.
Further metadata configuration options can be found in the official specification hereConfiguration Tip: The
key,x5c,x5cReferences, andurlHostparameters set service-wide defaults that apply to all verification sessions. These can be overridden per-session during verification session creation if needed. To usex5cReferences, attach an X.509 Store as a dependency of the verifier.urlHost(optional): String - Service-wide default base URL used to construct the QR code link or deep link for cross-device flows. Applied to all verification sessions unless overridden per-session. Defaults to"openid4vp://authorize"for standard OID4VP flows. For conformance testing with a browser-based authorization endpoint, use a full HTTPS URL. Not applicable for DC API flows (derived from request body instead).key(optional): Object - Service-wide default signing key for authorization request JWTs. Applied to all verification sessions unless overridden per-session. Must be a serialized key in the format{"type":"jwk","jwk":{...}}. Whensigned_request: trueorencrypted_response: trueis set during verification session creation, a signing key is required — either configured here as a default or included in the verification session setup body.x5c(optional): Array of Strings - Service-wide default X.509 certificate chain for the verifier's signing key. Applied to all verification sessions unless overridden per-session. Must be an ordered chain in PEM or DER-encoded, Base64-encoded format where the first certificate corresponds to thekey. Required when usingx509_san_dns:orx509_hash:as theclientIdformat, as wallets will use the certificate chain to verify the verifier's identity. Also explicitly required for signed Annex C (ISO 18013-7) requests. The leaf must chain to the wallet's configured trust anchors. If KeyUsage is present it must includedigitalSignature; if absent, RFC 5280 treats the key as unrestricted. If ExtendedKeyUsage is present it must include TLSclientAuth(1.3.6.1.5.5.7.3.2) or mdoc reader authentication (1.0.18013.5.1.6); if absent, EKU is unrestricted. Include both extensions when issuing verifier Request Object leaves.x5cReferences(optional): Array of Strings - Service-wide default X.509 Store certificate targets, e.g.waltid.tenant1.x509-store.cert1. Applied to all verification sessions unless overridden by sessionx5cReferencesor sessioncore.x5c. The store must be attached as a dependency.
Response Codes
201- Service created successfully.
Next Steps
- Verify credentials — create your first verification session.
- Default Requests — stop repeating the same verification session body. Save your usual verification query and settings once, then create sessions with just
{}.
Last updated on September 29, 2026
