Stop wrestling with OpenAPI specs — SpecLynx OpenAPI Toolkit delivers the most effective way to author and manage your API specs, bringing unprecedented ease, pinpoint accuracy, and unmatched power directly to your VSCode workflow.
SpecLynx OpenAPI Toolkit is engineered for clarity, control, and confidence, enabling you to focus on designing exceptional APIs.
Get full YAML/JSON autocompletion, inline documentation hints, validation, linting, and live preview as you type — so you catch errors before they cost you time. OpenAPI Toolkit surfaces context-aware suggestions for paths, parameters, responses, components, ...; flags missing or mismatched fields instantly; and renders a side-by-side spec-to-UI preview that updates with every keystroke. Say goodbye to manual spec checks and hello to a fluid authoring experience that keeps your API specs accurate and up-to-date.
- Powered by a powerful Language Server
- JSON Schema Validation
- Semantic Validation & Linting
- Spectral Validation & Linting
- OpenAPI Description dereferencing
- Workspace-Wide Operations
All these commands — and more — are just a keystroke away in VS Code, so you can focus on designing great APIs instead of wrestling with tooling.
SpecLynx OpenAPI Toolkit is crafted by industry veterans, Vladimír Gorej and Francesco Tumanischvili, who bring over 15 years of dedicated experience maintaining and evolving Swagger/OpenAPI tools. Their unparalleled expertise ensures you receive a solution with battle-tested reliability and best practices meticulously baked into every feature.
OpenAPI Toolkit provides advanced editing, processing, rendering, and execution capabilities for Swagger/OpenAPI files (2.0, 3.0, 3.1). These include an editor experience — offering validation/linting, completion, documentation, syntax highlighting, reference navigation, and more — along with a preview panel (based on Swagger UI) for rendering the OpenAPI document and allowing interaction and execution.
Several capabilities are unique in the VS Code OpenAPI ecosystem, such as Spectral support in the web, custom semantic linting, in-context documentation (including in completion items), full JSON/YAML parity, and rich reference handling.
We are actively expanding the feature set and fixing bugs; this documentation will be updated accordingly.
JSON and YAML — OpenAPI Toolkit provides the same level of support for OpenAPI specs written in JSON or YAML. It also aims to provide editor capabilities even for not-well-formed documents (for example, offering completion and syntax highlighting where possible).
Swagger/OpenAPI 2.0, OpenAPI 3.0, and 3.1 — OpenAPI Toolkit supports all of these versions with a consistent feature set.
Web support — OpenAPI Toolkit is designed to run both on Desktop and in Web environments such as vscode.dev, github.dev, and GitHub Codespaces. It is one of the few extensions that deliver advanced OpenAPI editing and validation/linting in the web environment.
When you hover over a keyword (node key) in the document, the extension shows full, context-aware documentation in a hover panel that corresponds to the selected construct and matches the official specification.
The same documentation is also shown in the details pane of completion items. See the “Completion / Suggestions” section below.
OpenAPI Toolkit provides an enriched completion experience. Under the hood, completion is driven by a semantic understanding of the node where completion is triggered, making suggestions far more precise and useful than standard JSON-Schema-based completion.
Each completion item includes full documentation (the same content shown in hover).
Tip: If the documentation panel doesn’t appear to the right of the completion label, click the > icon that appears when you hover the completion entry.
When completion is triggered within the value of a $ref field, the editor offers suggestions of compatible targets found in the document (this will be expanded to include documents across the workspace). It also displays the referenced content in the completion box, providing an in-context view of potential references without losing focus
Suggestions adapt to related fields. For example, if a schema sets type: integer, the format suggestions include only compatible values.
Hovering over the value of a $ref field displays the referenced content in the hover box, providing an in-context view of references without losing focus.
Right-click the value of a $ref field and choose Go to Definition (or press F3) to jump to the reference target—either within the current file or in another file in the workspace.
Right-click a key (for example, under components.schemas) and choose Go to References to open a panel listing available references to jump to.
Right-click a key (for example, of a schema) and choose Find All References to open the References panel listing every usage of the selected target.
Right-click inside an OpenAPI document or right-click the file in the Explorer, then choose OpenAPI Toolkit → Dereference API Document to save a dereferenced copy locally. The default output name is {filename}-dereferenced.{extension}.
OpenAPI Toolkit provides semantic syntax highlighting, going beyond basic keyword coloring. Specific OpenAPI elements—such as operations, schemas, and reference objects—are highlighted with distinct colors and font styles. This helps you quickly recognize and distinguish different parts of an API definition, improving readability and navigation in complex specifications.
- Validation — Checks that the document conforms to the OpenAPI and JSON Schema specifications.
- Linting — Analyzes an OpenAPI document against a configurable ruleset. Unlike validation (which only checks spec conformance), linting enforces best practices, style guidelines, and quality standards. It can catch issues such as inconsistent naming, missing descriptions, or patterns that harm API usability—even when the document is technically valid.
- Semantic validation — Validates using rules that target semantic properties of elements (e.g.,
operation,schema) rather than only applying JSON Schema. This enables more precise checks and clearer diagnostics (including highlighting the exact key, value, or child node that’s wrong). - Semantic linting — Lints using rules that can target semantic element types and/or JSONPath expressions. Compared to tools that only support JSONPath, this hybrid approach simplifies writing targeted rules (including for nested elements) and yields more precise editor markings.
OpenAPI Toolkit supports three modes, which you can combine:
- JSON Schema validation — Standard validation based on OpenAPI JSON Schemas
- Spectral validation and linting
- Semantic validation and linting
By default, JSON Schema validation and semantic linting are enabled. You can change this in the extension settings. Semantic validation is currently disabled by default because it has not yet completed a full compliance test cycle; once complete, it is expected to become the default validation method.
To enable Spectral-based checks:
- Enable Apply Spectral Validation in the extension settings.
- Provide a ruleset by either:
(a) adding a
.spectral.json,.spectral.yaml, or.spectral.ymlat the root of your workspace, or (b) setting the Spectral ruleset file path in the extension settings, or via the command OpenAPI Toolkit: Pick Spectral Validation/Linting Rules File (available from the editor context menu or the Explorer).
Refer to the Spectral documentation for ruleset format details.
Enable Apply Semantic Validation in the extension settings. No rules file is required to run the built-in semantic validation checks.
To run semantic linting:
- Enable Apply Semantic Linting in the extension settings.
- Provide a ruleset by either:
(a) adding a rules file at the workspace root named
.speclynx.json,.speclynx.yaml,.speclynx.yml(or without the leading dot), or (b) setting the semantic ruleset file path in the extension settings, or via the command OpenAPI Toolkit: Pick Semantic Validation/Linting Rules File (available from the editor context menu or the Explorer).
Semantic lint rules are defined in JSON or YAML. A ruleset typically includes:
- Rule ID and description/message
- Severity (e.g., error, warning, info)
- Target selector: a semantic element type (e.g.,
operation,schema,parameter, etc.) and/or a JSONPath for precise targeting - Condition(s) to evaluate (e.g., required fields, naming patterns, min/max constraints)
- Optional fixes or suggestions (when applicable)
A separate section provides the complete rule schema and examples. (If you don’t see it yet, it will be added as the rules stabilize.)
- callback
- components
- contact
- content
- definitions
- discriminator
- encoding
- example
- external-documentation
- header
- headers
- info
- items
- license
- link
- media-type
- oauth-flow
- oauth-flows
- openapi
- openapi3_0
- openapi3_1
- operation
- parameter
- parameters-definitions
- path-item
- paths
- path-template
- reference
- request-body
- response
- responses
- responses-definitions
- schema
- scopes
- security-definitions
- security-requirement
- security-scheme
- server
- server-variable
- swagger
- tag
- xml
(These are the current high-level element types recognized by the semantic engine.)
The Preview panel (powered by Swagger UI) renders the current OpenAPI document and lets you interact with it:
- Live rendering — Quickly verify how changes look without leaving the editor
- Server selection & auth — Choose servers and authorize requests where applicable
- Try it out — Execute operations directly from the preview to validate requests/responses during development
This helps you validate the specification from both a structural and a consumer point of view.