---
title: "Default Requests"
description: "Store a partial request body on an Enterprise service operation so callers only send the fields that change."
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/administration/services/configuration/default-requests
generated: 2026-10-01
---
# 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](https://docs.walt.id/enterprise-stack/administration/services/configuration/view.md). Configuration is the service document (keys, URLs, metadata). A default request is a reusable set of request values for one mutating operation.

**Note:**

Default requests are **opt-in per service instance**. Creating a service does not store any default requests. `PUT` a document to enable merge for that operation; `DELETE` it to turn merge off again.

## Which Services Support This

The `/default-requests` endpoints exist on these services:

| Service | API prefix | Useful operation |
|---|---|---|
| Verifier2 | `/v2/{target}/verifier-service-api` | `create-verification-session` |
| Wallet2 | `/v2/{target}/wallet-service-api` | `wallet2-present-credential`, `wallet2-receive-credential-authorized` |
| X.509 Certificate | `/v1/{target}/x509-service-api` | `create-iaca-certificate`, `create-document-signer-certificate` |
| DID | `/v1/{target}/did-service-api/dids` | `create-did-key`, `create-did-web` |
| VICAL | `/v1/{target}/vical-service-api` | `publish-vical` |
| Client Attestation | `/v1/{target}/client-attester-api` | `attest-client` |
| Trust Registry | `/v1/{target}/trust-registry-api` | `resolve-certificate` |

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.

**Option: CURL**

**Endpoint:** `PUT /v2/{target}/verifier-service-api/default-requests/{operation}` | [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) - `{organization}.{tenant}.{serviceId}`, for example `waltid.tenant1.verifier1`.
- **operation**: _String_ (required) - Operation identifier from the corresponding endpoint's OpenAPI description, for example `create-verification-session`.

**Header Parameters**

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

**Body Parameters**

- The body is a **partial** request body of `{operation}`. Send only the fields that should be defaulted. Unknown or misspelled keys are rejected here, not later when the operation runs.

##### Example Response `200 OK`

The stored document is echoed back.

**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 `{operation}` is unknown for this service.

🎉 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.

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

To override part of the default, send only those keys. Nested objects merge; arrays replace:

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

That request keeps `signed_request`, `encrypted_response`, and `expiration_duration` from the default, sets `sessionId`, and **replaces** the DCQL credentials array with the mDL query.

**Path Parameters**

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

**Header Parameters**

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

---

## List, Read, and Clear

**Option: CURL**

**List** — `GET /v2/{target}/verifier-service-api/default-requests`

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

Returns a JSON object keyed by operation. Operations with no default are omitted. Requires `view-default-requests`.

**Read one** — `GET /v2/{target}/verifier-service-api/default-requests/{operation}`

`404` when that operation has no default.

**Clear** — `DELETE /v2/{target}/verifier-service-api/default-requests/{operation}`

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

**Response Codes**

- `204` — No default is configured for that operation any more. Idempotent: clearing an unset operation also returns `204`.
- `401` / `403` — Authentication or authorization failure.
- `404` — Service not found, or `{operation}` is unknown.

---

## Next Steps

- Service guides: [Verifier2](https://docs.walt.id/enterprise-stack/services/verifier2-service/default-requests.md), [Wallet2](https://docs.walt.id/enterprise-stack/services/wallet2-service/default-requests.md), [X.509](https://docs.walt.id/enterprise-stack/services/x509-service/default-requests.md), [DID](https://docs.walt.id/enterprise-stack/services/did-service/default-requests.md), [VICAL](https://docs.walt.id/enterprise-stack/services/vical-service/default-requests.md), [Client Attestation](https://docs.walt.id/enterprise-stack/services/client-attestation-service/default-requests.md), [Trust Registry](https://docs.walt.id/enterprise-stack/services/trust-registry-service/default-requests.md).
- [View service configuration](https://docs.walt.id/enterprise-stack/administration/services/configuration/view.md) — rotate keys and URLs without dropping stored defaults.
- [Service operations overview](https://docs.walt.id/enterprise-stack/administration/services/overview.md).