---
title: "Default Requests"
description: "Store your usual verification session settings once so each create-verification-session call only sends what changes."
stack: "Enterprise Stack (commercial) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/services/verifier2-service/default-requests
generated: 2026-10-01
---
# Default Requests

Every time you create a verification session, you send the same things: the flow type, the credential query, the expiry. **Default requests** let you save those once on your Verifier2 service, so creating a session only needs the values that differ, or nothing at all.

**Note:**

Default requests are **optional**. Nothing on this page is required to verify credentials. Use it once you notice you are repeating the same verification session body.

## What Changes

Without a default, every session create carries the full body:

```json
{
  "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"] }]
        }
      ]
    }
  }
}
```

With that same body stored as a default, the call becomes:

```json
{}
```

The service fills in everything you left out. Anything you *do* send in the call wins over the stored value.

## Prerequisites

- A Verifier2 service. See [Setup](https://docs.walt.id/enterprise-stack/services/verifier2-service/setup.md).
- A bearer token with the `update-default-requests` permission and the permission to create verification sessions. Both are needed to store a default.

## Step 1: Store a Default

Store the body from the example above with a `PUT`. The last part of the URL, `create-verification-session`, names the API call the default applies to: the one behind `POST /v2/{target}/verifier-service-api/verification-session/create`. The body is an ordinary verification session request. Leave out any field you would rather send per call, except `flow_type`, which must always be included.

**Option: CURL**

**Endpoint:** `PUT /v2/{target}/verifier-service-api/default-requests/create-verification-session` | [API Reference](https://enterprise.sandbox.walt.id/swagger/index.html)

##### Example Request

```bash
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"] }
          ]
        }
      ]
    }
  }
}'
```

**Path Parameters**

- **orgID**: _String_ (required) - Organization host alias. For the sandbox organization `test`, the base URL is `https://test.enterprise-sandbox.waltid.dev`.
- **target**: _resourceIdentifier_ (required) - `{organizationID}.{tenantID}.{verifierServiceID}`, for example `waltid.tenant1.verifier1`.

**Header Parameters**

- **Authorization**: _String_ (required) - Bearer token. Format: `Bearer {yourToken}`.

**Body Parameters**

- The body is a **partial** `create-verification-session` request. It accepts the same fields as [creating a session](https://docs.walt.id/enterprise-stack/services/verifier2-service/credential-verification/sd-jwt-vc-oid4vp.md), and you can send a subset of them. **`flow_type` is required**, because it selects the request shape; a body without it is rejected with `400`. Unknown or misspelled keys are rejected now, not later when a session is created. Missing values such as `core_flow` are not checked until a session is created, so a partial default is accepted as long as the call supplies the rest.

##### Example Response `200 OK`

The stored document is echoed back.

```json
{
  "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"] }]
        }
      ]
    }
  }
}
```

**Response Codes**

- `200` - Default request stored.
- `400` - The document is not a valid partial body for this operation.
- `401` / `403` - Authentication or authorization failure. `update-default-requests` and the operation's own permission are both required.
- `404` - Service not found, or the operation name is unknown.

## Step 2: Create a Session

Send an empty body. The stored default supplies everything.

**Option: CURL**

**Endpoint:** `POST /v2/{target}/verifier-service-api/verification-session/create` | [API Reference](https://enterprise.sandbox.walt.id/swagger/index.html)

##### Example Request

```bash
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 '{}'
```

**Path Parameters**

- **orgID**: _String_ (required) - Organization host alias.
- **target**: _resourceIdentifier_ (required) - `{organizationID}.{tenantID}.{verifierServiceID}`.

**Header Parameters**

- **Authorization**: _String_ (required) - Bearer token. Format: `Bearer {yourToken}`.

**Body Parameters**

- Optional once a complete default is stored. Any field you send overrides the stored value.

##### Example Response `200 OK`

The response is the same as for any session create. See [Verifying SD-JWT VC Credentials](https://docs.walt.id/enterprise-stack/services/verifier2-service/credential-verification/sd-jwt-vc-oid4vp.md#example-response) for the fields.

**Response Codes**

- `200` - Session created.
- `400` - The merged request is not a valid session request, for example when neither the stored default nor the call provides `core_flow`, or when no default is stored and the call omits `flow_type`.
- `401` / `403` - Authentication or authorization failure.

### Override Part of the Default

To change one thing, send only that. Nested objects merge key by key, but **arrays are replaced, not appended**.

```json
{
  "core_flow": {
    "dcql_query": {
      "credentials": [
        {
          "id": "mdl",
          "format": "mso_mdoc",
          "meta": { "doctype_value": "org.iso.18013.5.1.mDL" }
        }
      ]
    }
  }
}
```

This session keeps `flow_type`, `signed_request`, `encrypted_response` and `expiration_duration` from the default, and **replaces** the PID credential query with the mDL one.

## Good to Know

- **Explicit values win**, including `false` over a stored `true`.
- **Arrays and primitives are replaced wholesale.** There is no "add to the list".
- **Nothing to clear with `null`.** To remove a default, delete it (see below).
- **Clearing is safe to repeat.** `DELETE` returns `204` even when nothing was stored.

## Read or Remove a Default

- List all stored defaults: `GET /v2/{target}/verifier-service-api/default-requests` (needs `view-default-requests`).
- Read one: `GET …/default-requests/create-verification-session`. Returns `404` if none is stored.
- Remove one: `DELETE …/default-requests/create-verification-session`.

Full details, permissions and the other services that support default requests: [Default Requests](https://docs.walt.id/enterprise-stack/administration/services/configuration/default-requests.md).