Tools

The ruleset format runs in a lot more places than the CLI that created it. This page is two lists: the third-party tooling that already supports the format, and the open-source governance tools API Commons has built on it.

Both lists make the same argument. Rulesets are not configuration for one linter — they are a portable artifact that commercial platforms, alternative engines, CI tooling, and developer portals all consume. That is exactly why the format needs to be written down independently of any one implementation.

---

Third-party tooling that supports the format

Other people’s tools, listed because the format’s real footprint is theirs, not ours. Every row links to the vendor or project documentation that substantiates the claim — nothing here is inferred. This is a working list of tooling you can actually pick up and use; the wider landscape, including alternative engines and prior art with their own rules models, is mapped with evidence on the implementations page.

Commercial platforms

These are products you pay for that read the same ruleset file you keep in your repository.

Product	Who ships it	How it uses the ruleset format	Evidence
SwaggerHub / Swagger Studio	SmartBear	API Governance imports Spectral rulesets as organization style guides, with a Spectral ruleset editor in the product and spectral:upload / spectral:download in the CLI	Docs
Azure API Center	Microsoft	Lints API definitions on add or update with Spectral as the analyzer and spectral:oas as the default analysis profile; rulesets are authored locally and deployed back	Docs
Apigee API hub	Google Cloud	A built-in Spectral linter validates every OpenAPI added to an API version; custom “style guides” are uploaded rulesets	Docs
Postman	Postman	Configurable API governance and security rules are Spectral v6 rules, including custom JavaScript functions	Docs
IBM API Connect	IBM	The governance service validates OpenAPI against Spectral rulesets — pre-configured global rulesets named spectral-* and version-matched to upstream, plus custom org rulesets restricted to the built-in core functions	Docs
Axway Amplify Engage	Axway	Rulesets execute automatically on service discovery, so every discovered service carries a compliance grade before anyone opens it	Write-up
Insomnia / Inso CLI	Kong	Picks up a .spectral.yaml beside the specification, defaults to the standard OAS ruleset, and supports extends for your own	Docs
Bump.sh	Bump.sh	Lints with vacuum using the Spectral OAS ruleset by default; existing rulesets carry over through the spectral: compatibility alias	Docs

Open-source tooling

Tool	What it does	Source
vacuum	The independent Go engine, and the most complete alternative implementation — states 100% compatibility with Spectral rulesets, and is the engine several products above run underneath	GitHub
IBM OpenAPI Validator	IBM’s open-source validator will pick up a standard Spectral ruleset from the working directory or any containing directory, in preference to its own IBM Cloud Validation Ruleset	GitHub
decK file lint	Kong’s gateway configuration CLI lints any JSON or YAML — gateway config as readily as OpenAPI — against Spectral-compatible rulesets, implemented on vacuum	Docs
api-oas-checker	The Italian government’s checker — a static browser application that lints against the national API guidelines, with the rules maintained as a separate public ruleset repository	GitHub
Backstage API Docs Spectral Linter	Adds a linter tab to API entities inside an internal developer portal, with a default ruleset or a per-entity one set by annotation	GitHub

Adjacent, and worth knowing

Project	What it is	Source
SpecLynx	An independent line of API tooling — a CLI, a browser-based editor, and a VS Code toolkit — built on its own fork of ApiDOM, the semantic parser underneath much of the serious Swagger-era tooling. It does not consume the ruleset format today; it is listed because it is among the most capable and least known parsing and validation stacks in this space, and because semantic parsing is what rule authoring has always been missing	GitHub

Maintain something that belongs on this list, or something listed here wrongly? Corrections and additions are merged on sight — open a pull request or say so in the discussion.

---

Built by API Commons

I’ve been hard at work filling in the gaps in the services I offer as the API Evangelist with the tooling needed by the folks I know building API governance programs within enterprises. These are modular open-source solutions that help enterprises standardize and govern how they produce and consume APIs.

They are listed because they demonstrate something specific: the format is already doing work that has nothing to do with the CLI that runs it. Registries, baselines, scorecards, coverage reports, waivers, federation — none of that is linting. All of it depends on rules being a durable, portable, inspectable artifact.

Tool	What it does	Source
api-validator	The deepest integration — validates OpenAPI, AsyncAPI, Arazzo, and JSON Schema in the browser	GitHub
ruleset-commons	A registry of adoptable, provenanced rulesets — where rules come from, and whether you can trust them	GitHub
governance-pipeline	A reference CI/CD governance pipeline you can fork	GitHub
governance-baseline	Snapshot the violations you already have; fail only new ones. The adoption unblocker for a legacy estate	GitHub
governance-scorecard	The longitudinal view — health over time, not a point-in-time verdict	GitHub
governance-coverage	How much of a description your rules actually check	GitHub
governance-certification	Tamper-evident certificates for a governance result	GitHub
governance-waivers	Sanctioned, owned, expiring exceptions — because the alternative is people quietly ignoring the linter	GitHub
governance-agent-export	Export a ruleset into agent-native artifacts, so the rules reach the agent before it authors, not after	GitHub
api-governance-graph	Binds the governance building blocks — policies, rules, guidance, lifecycle — into one view	GitHub
codefirst-governance	Meets annotation and code-first teams where they actually are	GitHub
rule-federation	A federated rule registry — a central baseline with local overrides, for organizations that are not one team	GitHub

All of them live under API Commons, run in the browser or in CI with no backend required, and are open source under Apache-2.0.

---

Why this matters for the specification

Every tool on this page — the vendors at the top as much as the API Commons tools underneath — had to answer the same question: what exactly is a valid ruleset? And the only available answer was “whatever the linter accepts today,” discovered by reading its source.

That is a workable answer for one tool. It is not a workable answer for a registry that publishes rulesets, a federation layer that merges them, a certification tool that has to prove what was checked, or an agent export that has to translate them into something else entirely.

A written specification is what turns rules from configuration into an artifact. That is the argument these tools make better than any post could.

---