Engine and rule-set versions, and what each release added
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.
Request
- Base URL: https://api.attestwire.com
- URL: https://api.attestwire.com/v1/versions
- Auth: none required
Response
The running engine, the KoSIT record, and the release history.
Example response
{
"engine": "@attestwire/en16931",
"engine_version": "0.14.1",
"ruleset": "en16931@0.14.1",
"kosit_conformance": {
"recorded": "2026-09-24",
"validator": "1.6.3",
"configuration": "3.0.2",
"configuration_published": "2026-08-31"
},
"releases": [
{
"version": "0.14.1",
"rules_added": [
"BR-13"
]
}
]
}Changes
No recorded changes to this operation across all 1 revision of this API.