#Default Requests

Default requests let you save the fields you would otherwise send on every call to a service, such as a verification query or a signing key, so each call only carries what changes. You store them once with a PUT. From then on, whenever that operation runs, the stored values fill in any field the caller leaves out. Values sent in the call always win, and if nothing is stored as a default request, the operation behaves exactly as before.

An operation is one API call, identified by the name shown in OpenAPI as Operation: '<operation>'. For example, create-verification-session is the operation behind POST …/verification-session/create. Technically, the stored document is a partial JSON request body that is deep-merged underneath the body the caller sends.

This is separate from service configuration. Configuration is the service document (keys, URLs, metadata). A default request is a reusable set of request values for one mutating operation.

#Which Services Support This

The /default-requests endpoints exist on these services:

Every JSON-object POST / PUT on those services can technically store a default. Use the operations above: they are the ones with stable fields (flow setup, holder key, org identity) and per-call fields (offers, certificates, session ids) that you still send on each request.

#Merge Rules

• Nested objects merge key by key.
• Arrays and primitives are replaced wholesale. Sending a new dcql_query.credentials array replaces the defaulted query; it is not appended.
• Merge happens on raw JSON before deserialization, so an explicit false can override a defaulted true.
• An empty body is valid once a complete default is stored.
• There is no delete-by-null sentinel.

#Permissions

• view-default-requests — list or read stored defaults.
• update-default-requests — set or clear a default.

PUT and DELETE also require the permission of the operation itself. On the X.509 service, someone who can create document signers cannot edit the IACA default unless they also have the IACA create permission.

These permissions are separate from view-service-configuration / update-service-configuration. Updating a URL or signing key does not drop stored default requests.

#Set a Default Request

The examples below use Verifier2. Swap the API prefix and {operation} for the other services.

curl -X 'PUT' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v2/{target}/verifier-service-api/default-requests/create-verification-session' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{
  "flow_type": "cross_device",
  "core_flow": {
    "signed_request": false,
    "encrypted_response": false,
    "expiration_duration": "PT5M",
    "dcql_query": {
      "credentials": [
        {
          "id": "pid",
          "format": "dc+sd-jwt",
          "meta": {
            "vct_values": [
              "https://credentials.example.com/identity_credential"
            ]
          },
          "claims": [
            { "path": ["family_name"] }
          ]
        }
      ]
    }
  }
}'

🎉 You've stored a default. Session creation can now omit the fields above.

#Invoke the Operation

With a complete default, the body may be empty. With a partial default, send only what varies.

curl -X 'POST' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v2/{target}/verifier-service-api/verification-session/create' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{}'

{
  "core_flow": {
    "sessionId": "session-1",
    "dcql_query": {
      "credentials": [
        {
          "id": "mdl",
          "format": "mso_mdoc",
          "meta": { "doctype_value": "org.iso.18013.5.1.mDL" }
        }
      ]
    }
  }
}

#List, Read, and Clear

curl -X 'GET' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v2/{target}/verifier-service-api/default-requests' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}'

curl -X 'DELETE' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v2/{target}/verifier-service-api/default-requests/create-verification-session' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}'

#Next Steps

• Service guides: Verifier2, Wallet2, X.509, DID, VICAL, Client Attestation, Trust Registry.
• View service configuration — rotate keys and URLs without dropping stored defaults.
• Service operations overview.