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.
OpenAPI Authoring
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.
Built by Veterans
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.
What is it?
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.
Capabilities
Editor
Foreword
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.
In-context OpenAPI Documentation (hover)
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.
Completion / Suggestions
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.
Completion docs
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.
References completion
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
Context-aware completion (e.g., type: integer → format)
Suggestions adapt to related fields. For example, if a schema sets type: integer, the format suggestions include only compatible values.
References
Reference target content in hover
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.
Go to definition (F3)
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.
Go to references
Right-click a key (for example, under components.schemas) and choose Go to References to open a panel listing available references to jump to.
Find all references
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.
Dereference command
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}.
Syntax Highlighting
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 and Linting
Definitions
- 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.
Validation/Linting modes
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
Default configuration
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.
Spectral validation/linting
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.yml at 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.
Semantic validation
Enable Apply Semantic Validation in the extension settings. No rules file is required to run the built-in semantic validation checks.
Semantic linting
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 linting rules (overview)
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.)
Supported major element “types” for semantic checks
- 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.)
Preview
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.
