The implementation landscape
The tool is one implementation among many. The format is the thing that matters.
That is the claim this whole effort rests on, and a claim is worth very little without a list behind it. This page is the list — every engine that runs the Spectral ruleset format, every product that embeds it behind its own interface, and the adjacent tooling that solves the same problem a different way.
It exists for a second reason too. The recurring pattern in this ecosystem is vendors independently building on the format, wrapping it in their own facade, or reimplementing it — each of them solving the same problems privately, because there was never a specification to solve them against. Naming that work publicly is how parallel private effort becomes an ecosystem.
How this list is kept
- Evidence, not opinion. Every relationship claim links to something checkable. No performance claims repeated without a reproducible benchmark.
- No ranking and no scoring. The project that maintains one of these implementations does not get to score the others.
- Corrections take priority. If you maintain something listed here and this page is wrong
about it, open a pull request against
_data/implementations.ymland it gets merged on sight. Being wrong about someone else’s project in public is worse than being incomplete. - Machine-readable first. The data file is the source of truth; this page renders from it.
Engines
Implementations that execute the ruleset format directly. These are the ones a conformance suite adjudicates between.
spotlight-tools
TypeScript / JavaScript · runs in the browser
The reference implementation — a maintained build of the linter at v6.16.2, with the inherited telemetry removed and issues open. One conforming engine among several, not the definition of correct.
Spectral (upstream)
TypeScript / JavaScript · runs in the browser
Where the format comes from. Still the most widely installed implementation, and the reason a specification is needed — for years the only definition of a valid ruleset was whatever this codebase accepted.
vacuum
Go
The independent Go implementation, actively maintained, and the most complete alternative engine. Has added capabilities of its own — rule categories among them — which is exactly the kind of divergence a written specification and a conformance suite should be able to absorb rather than argue about.
Embedded in products
The least visible and most significant category — the format doing load-bearing work inside somebody else's product, usually behind an interface that never mentions it. This is what "sinking below the waterline" looks like in practice, and it is the strongest argument for the format existing independently of any one tool.
IBM OpenAPI Validator
TypeScript / JavaScript
IBM's validator supports Spectral rules and will pick up a standard Spectral ruleset file from the working directory or any containing directory, in preference to its own IBM Cloud Validation Ruleset. A clear example of the pattern this effort exists to surface — the format doing load-bearing work behind somebody else's interface.
Azure API Center
hosted service
Microsoft's API governance service lints API definitions on add or update, with Spectral as the analyzer and the `spectral:oas` ruleset as the default analysis profile. Rulesets are customized locally in the VS Code extension and deployed back. Documented as supporting Spectral as the only analyzer type.
SwaggerHub / Swagger Studio
hosted service
SmartBear's API Governance imports Spectral rulesets as organization style guides, ships a Spectral ruleset editor in the product, and exposes `spectral:upload` / `spectral:download` through the CLI. The company that acquired the engine also consumes the format as a portable artifact in its own platform.
Apigee API hub
hosted service
Google Cloud's API hub ships a built-in Spectral linter that validates every OpenAPI added to an API version, reporting findings in the console. What the product calls a "style guide" is an uploaded ruleset, with the documented constraint that it cannot reference remote URLs in `extends` — a portability limit worth specifying against.
IBM API Connect
hosted service
The governance service validates API and product documents against Spectral rulesets from the API Manager UI, the Designer, or the toolkit CLI. Pre-configured global rulesets are named `spectral-*` and versioned to match upstream, while custom provider-organization rulesets are restricted to the built-in core functions — a vendor pinning itself to the format's version and its function set, with no specification to pin to.
Axway Amplify Engage
hosted service
Rulesets execute automatically as services are discovered, so every discovered API carries a compliance grade before anyone opens it. Governance applied at discovery rather than at authoring — a different insertion point for the same artifact.
Insomnia / Inso CLI
TypeScript / JavaScript
Kong's API client picks up a `.spectral.yaml` sitting beside the specification, defaults to the standard OAS ruleset, and supports `extends` for organization rules — across local, cloud and Git-synced projects, with the same file working in the desktop app and in CI via Inso.
decK file lint
Go
Kong's gateway configuration CLI lints any JSON or YAML file against Spectral-compatible rulesets, implemented on the Go engine. Notable because the target is gateway configuration, not an API description — the format being applied well outside the problem it was written for.
api-oas-checker
JavaScript
The Italian government's OpenAPI checker — a static browser application, no server or database, that lints against the national API guidelines with the engine running client-side. The rules are maintained as a separate public repository, which is what a national standard published as a ruleset actually looks like in practice.
Backstage API Docs Spectral Linter
TypeScript / JavaScript
A community plugin that adds a linter tab to API entities inside an internal developer portal, with a default ruleset or a per-entity one set by catalog annotation. The format reaching developers where they already are, through somebody else's interface.
Adjacent
Tooling that solves the same problem with its own rules model. Not competitors to be argued with — prior art to be learned from, and in several cases the reason a particular design decision in the format looks the way it does.
Redocly CLI
TypeScript / JavaScript
Its own linting engine and its own rules model, configured through `redocly.yaml` rather than a Spectral ruleset. Relevant here as substantial prior art on the same problem, and as a design comparison for anyone specifying a rules format.
SpecLynx
TypeScript · runs in the browser
An independent line of API tooling — a CLI (`overlay`, `validate`), a browser-based editor, and a VS Code toolkit — built on its own fork of ApiDOM, the semantic parser that underpins much of the serious Swagger-era tooling. Not a consumer of the ruleset format today, and among the most capable and least known parsing and validation stacks in this space.
Zally
Kotlin / Java
An API linter with its own rules model, written in a JVM language, built by an organization that publishes its API guidelines publicly. Prior art for the "mandatory design rules as executable checks" pattern that European public-sector programmes later took much further.
Relationship not established
Believed relevant, but the relationship to the ruleset format has not been verified here. Listed openly rather than guessed at — corrections from the maintainers are the fastest way to fix these.
What is missing, and it is a lot
The hardest category to map is in-house implementations. Several large enterprises wrote their own engine rather than depend on an unmaintained one, and several more run the incumbent engine behind an internal validation platform that nobody outside the company has ever heard of. None of that is visible from a package registry.
That invisibility is not a curiosity — it is the reason every conversation about a permanent home for the format stalls. Who actually uses this? has never had a public answer.
If you run one of these, saying so — publicly or privately — does more for the format than any amount of code.
What this list is for
Once the conformance suite exists, this page becomes something better than a map: a register of what conforms, run and reported the same way for every engine, with the output published. That is the point at which “compatible with the ruleset format” stops being a marketing claim and becomes a testable one — and the point at which the implementers doing quiet parity work finally get credit for it.
Maintain an implementation, or know one that is missing? The roundup is tracked in the open.
The roundup issue → Discussion