---
title: "Engine and rule-set versions, and what each release added"
method: GET
path: "/v1/versions"
tags: ["Meta"]
---

# Engine and rule-set versions, and what each release added

`GET /v1/versions`

## Request

- Base URL: `https://api.attestwire.com`
- URL: `https://api.attestwire.com/v1/versions`
- Auth: none required

What this deployment is running, and what changed when. Free, unauthenticated, and cacheable for five minutes.

THE QUESTION IT ANSWERS is "why did a document that passed last month start failing?". Pin the npm library and your CI is bit-identical forever; the hosted API always runs the current rule set, because a compliance service that froze its rules would be answering last quarter's regulation. Point a weekly job at this endpoint and a rule id appearing in `rules_added` is your answer, without a support ticket.

Every metered response also carries a `provenance` block naming the engine version, rule set and profile that judged THAT document. This endpoint is the same information for the deployment as a whole, plus the release history.

`rules_added` is DERIVED from the engine's own changelog rather than typed, and the derivation is published in the body beside it: an id is attributed to the oldest release whose notes name it, which is usually — not always — the release that started enforcing it. Read it as where to look first, not as a specification. `rule_id_count` is every rule id the engine checks, which is more than the release notes have ever named.

## Response `200`

The running engine, the KoSIT record, and the release history.

- Versions: The body of GET /v1/versions: the running engine, the KoSIT record, and one entry per release of the engine.
  - `engine` string, required
  - `engine_version` string, required
  - `ruleset` string, required
  - `rule_id_count` integer, required: Every rule id the compiled engine checks — which is more than the release notes have ever named, so this will not equal the sum of the `rules_added` arrays below.
  - `kosit_conformance` KositConformance, required: When the official KoSIT validator was last run against this engine's committed fixtures, and with what. **NOTHING IS SENT TO KoSIT WHEN YOU CALL US.** This is a dated record of a check we ran on release, not a per-call verification, and it says nothing about YOUR document.
    - `recorded` string, date, required: The date of the last recorded full fixture run.
    - `validator` string, required: Version of the KoSIT standalone validator used.
    - `configuration` string, required: Version of the XRechnung validator configuration used.
    - `configuration_published` string, date, required: The date that configuration was published by KoSIT.
  - `releases` Release[], required: Newest first.
    - `version` string, required
    - `date` string, date, required
    - `rules_added` string[], required: The rule ids this release first named in the changelog. Derived, never typed — see `derivation` on the enclosing document. Empty for a release that named none.
  - `derivation` string, required: How `rules_added` is derived, published in the body so nobody over-reads the list. Prose; do not parse it.

## Other responses

- `500`: Unhandled fault while reading the version document. Never expected; the body carries no detail on purpose (a fault message can quote the offending value). Retry, and email hello@attestwire.com if it persists.

---

[API](https://skmtc.dev/attestwire/apis/attestwire-api.md) · [All operations](https://skmtc.dev/attestwire/apis/attestwire-api/llms.txt) · [OpenAPI document](https://skmtc.dev/attestwire/apis/attestwire-api/revisions/0036f8e043b2?raw)