Quovalis

API quickstart

From zero to a verdict in three steps. Base URL and full schemas live in the OpenAPI specification; everything below is the happy path.

Background reading for the terms this page uses: What is a QWAC? · QWAC vs QSealC · How qualified status is determined · Trusted lists and the LOTL · The tri-state verdict · The validation call · API key security

1. Get a key

Create an account, verify your email, then mint a key under API keys in the console. Keys look like qv_<prefix>_<secret> and are shown exactly once — only a hash is stored. Each key can carry an IP allowlist (see API key security).

2. Validate a certificate

POST a PEM certificate (optionally with intermediates) under a policy — POLICY_EIDAS_QWAC_V1 for website-authentication certificates, POLICY_EIDAS_QSEALC_V1 for electronic seals:

curl https://api.quovalis.eu/v1/validations \
  -H "Authorization: Bearer $QUOVALIS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "certificate": "-----BEGIN CERTIFICATE-----\n…\n-----END CERTIFICATE-----",
    "chain": ["-----BEGIN CERTIFICATE-----\n…\n-----END CERTIFICATE-----"],
    "policy": "POLICY_EIDAS_QWAC_V1",
    "options": { "checkRevocation": true }
  }'

Request bodies are capped at 256 KiB and chain takes at most 10 intermediates. The response pins the exact trust-list snapshot the verdict was computed against. A field that does not apply is an absent key, never null, and 64-bit integers such as sequenceNumber are JSON strings so no precision is lost:

{
  "id": "0198f3a2-7c11-7000-8000-3f9be1a2c001",
  "verdict": "VERDICT_VALID",
  "policy": "POLICY_EIDAS_QWAC_V1",
  "validatedAt": "2026-07-09T12:00:00Z",
  "certificate": { "subject": "CN=bank.example.com,…", "notAfter": "2027-01-01T00:00:00Z", … },
  "qualified": {
    "isQualified": true,
    "qcType": "QC_TYPE_WEB",
    "trustServiceProvider": { "name": "Example QTSP", "territory": "NL", "serviceStatus": "granted" }
  },
  "psd2": { "roles": ["PSD2_ROLE_PSP_AS", "PSD2_ROLE_PSP_AI"], "ncaId": "NL-DNB", "authorizationNumber": "PSDNL-DNB-123456" },
  "revocation": { "status": "REVOCATION_STATUS_GOOD", "method": "REVOCATION_METHOD_OCSP", "checkedAt": "2026-07-09T12:00:00Z" },
  "trustList": {
    "territory": "NL",
    "sequenceNumber": "87",
    "snapshotId": "0198f3a2-7c11-7000-8000-3f9be1a2c002"
  }
}

Verdicts are tri-state: VERDICT_VALID, VERDICT_INVALID (with a subIndication naming the dominant reason) or VERDICT_INDETERMINATE when the service could not obtain enough data — and an indeterminate result is never silently upgraded (why the third state exists is covered on the tri-state verdict). A validation outcome is always HTTP 200; errors use RFC 9457 problem documents. The result document and its absent-key rules are covered in depth on the validation call, and how the qualified answer is reached on qualified status.

3. Fetch stored results

# Re-served from the stored record — the same document every fetch, never recomputed.
curl https://api.quovalis.eu/v1/validations/0198f3a2-7c11-7000-8000-3f9be1a2c001 \
  -H "Authorization: Bearer $QUOVALIS_API_KEY"

Stored results stay fetchable for up to your plan's retention window — quotas, rate limits and retention per plan are on the pricing page.

More endpoints

Three read-only endpoints round out the API — full schemas in the OpenAPI specification. GET /v1/usage returns your current billing period at a glance: plan, quota, consumed, remaining, overage and your rate limit.

curl https://api.quovalis.eu/v1/usage \
  -H "Authorization: Bearer $QUOVALIS_API_KEY"

GET /v1/trustlist/providers lists the trust service providers and their CA/QC services from the current trust-list snapshot, filterable by territory and paginated with cursor/limit:

curl "https://api.quovalis.eu/v1/trustlist/providers?territory=NL" \
  -H "Authorization: Bearer $QUOVALIS_API_KEY"

GET /v1/trustlist/status reports ingestion health per territory — sequence numbers, snapshot ids, signature checks and staleness — so you can see exactly which trust state verdicts are being computed against:

curl https://api.quovalis.eu/v1/trustlist/status \
  -H "Authorization: Bearer $QUOVALIS_API_KEY"

Errors

All non-2xx responses are RFC 9457 problem documents (application/problem+json) with a type of urn:quovalis:problem:<suffix>; problem bodies carry a requestId to quote at support. A validation outcome is never an error: INVALID and INDETERMINATE verdicts arrive as HTTP 200. The full error table — every type suffix, status and the monthly-window resetAt member — is on the validation call page.

Good to know

  • Validation is not idempotent by design — every call produces a new, billable validation record.
  • A verdict is a technical assessment against published trust-list and revocation data — see the Terms for the documented non-claims.
  • Try certificates interactively in the console playground before writing any code.