Default Requests

Every VICAL publication repeats the same provider name. Default requests let you save it once on your VICAL service, so publishing needs no fields at all: the version ID becomes a generated UUID and the date the current time.

Default requests are optional. Nothing on this page is required to publish a VICAL.

What Changes

Without a default, a publish call must send vicalProvider. With it stored, the call becomes:

{}

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

Prerequisites

  • A VICAL service that can publish. See Setup.
  • A bearer token with the update-default-requests permission and the permission to publish. Both are needed to store a default.

Step 1: Store a Default

The last part of the URL, publish-vical, names the API call the default applies to: the one behind POST /v1/{target}/vical-service-api/publish.

CURL

Endpoint: PUT /v1/{target}/vical-service-api/default-requests/publish-vical | API Reference

Example Request
curl -X 'PUT' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{target}/vical-service-api/default-requests/publish-vical' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{
  "vicalProvider": "Example mDL Trust Provider"
}'

Path Parameters

  • orgID: String (required) - Organization host alias.
  • target: resourceIdentifier (required) - {organizationID}.{tenantID}.{vicalServiceID}, for example test.tenant1.vical-service.

Header Parameters

  • Authorization: String (required) - Bearer token. Format: Bearer {yourToken}.

Body Parameters

  • A partial publish request. Unknown or misspelled keys are rejected now, not when you publish.
Example Response 200 OK

The stored document is echoed back.

{
  "vicalProvider": "Example mDL Trust Provider"
}

Response Codes

  • 200 - Default request stored.
  • 400 - The document is not a valid partial body for this operation.
  • 401 / 403 - Authentication or authorization failure.

Step 2: Publish

Send an empty body. Each empty publish creates a new version.

CURL

Endpoint: POST /v1/{target}/vical-service-api/publish | API Reference

Example Request
curl -X 'POST' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{target}/vical-service-api/publish' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{}'

Body Parameters

  • Any field you send overrides the stored value, for example versionId or vicalProvider.
Example Response 201 Created

The response is the same as for any publication. See Publish a new VICAL version.

{
  "versionIdPath": "test.tenant1.vical-service.versions.6a3f73a2-3187-462c-a103-33c458216512",
  "version": "1.0",
  "entryCount": 1,
  "vicalProvider": "Example mDL Trust Provider",
  "date": "2026-09-29T11:03:19.716059Z"
}

Response Codes

  • 201 - VICAL version published.
  • 400 - The merged request is invalid, for example when no default is stored and the call omits vicalProvider.
  • 401 / 403 - Authentication or authorization failure.

Good to Know

  • Don't store versionId or the dates. They would be reused by every publish, and nextUpdate goes stale.
  • Defaults are not guardrails. Anyone allowed to publish can override any stored field.
  • Explicit values win. A call that sends vicalProvider publishes under that name instead.

Read or Remove a Default

  • List all stored defaults: GET /v1/{target}/vical-service-api/default-requests (needs view-default-requests).
  • Read one: GET …/default-requests/publish-vical. Returns 404 if none is stored.
  • Remove one: DELETE …/default-requests/publish-vical. Returns 204, also when nothing was stored.

Full details and permissions: Default Requests.

Last updated on September 29, 2026
Publish and Resolve VICAL VersionsVICAL Service