SpecLynx OpenAPI Toolkit

Why Choose SpecLynx OpenAPI Toolkit?

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.

One-Click Tooling

• Powered by a powerful Language Server
• JSON Schema Validation
• Semantic Validation & Linting
• Spectral Validation & Linting
• OpenAPI Description dereferencing
• JSON <-> YAML Conversion
• 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 format. It also aims to provide editor capabilities even for not-well-formed documents (for example, offering completion and syntax highlighting where possible).

OpenAPI Toolkit supports following OpenAPI versions with a consistent feature set:

• OpenAPI 2.0 (Swagger)
• OpenAPI 3.0.x
• OpenAPI 3.1.x

OpenAPI 2.0 (Swagger)

OpenAPI 3.0.x

OpenAPI 3.1.x

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 documentation

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:

1. JSON Schema validation — Standard validation based on OpenAPI JSON Schemas
2. Spectral validation and linting
3. 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:

1. Enable Apply Spectral Validation in the extension settings.
2. 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.

Create a Spectral ruleset

Use a Spectral ruleset

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:

1. Enable Apply Semantic Linting in the extension settings.
2. 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

These are the current high-level element types recognized by the semantic engine.

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

Formatting

SpecLynx OpenAPI Toolkit is capable of formatting your OpenAPI Documents, whether they are written in JSON or YAML. Formatting preferences, like tabSize or whether to use tabs or spaces (insertSpaces) are read directly from your VSCode settings.

JSON <-> YAML Conversion

Right-click inside an OpenAPI document or right-click the file in the Explorer, then choose OpenAPI Toolkit → Convert to YAML / Convert to JSON to convert the document from one format to the other and save locally. The default output name is {filename}.{target-extension}

Preview

The Preview panel renders the current OpenAPI document and lets you interact with it. Preview panel can be opened by opening the Command Palette (CTRL+Shift+P) and running the OpenAPI Toolkit: Show API Document preview command.

The extension supports multiple OpenAPI preview renderers. You can switch between them by setting speclynx.openapi.preview.renderer in your VS Code settings:

Renderer	Description	Default
scalar	Scalar API Reference	✅
swagger-ui	Swagger UI

In VS Code, go to File → Preferences → Settings, then search for @ext:SpecLynx.vscode-openapi-toolkit.

This will display all settings provided by the extension.

Scalar API Reference

SwaggerUI

Preview interactions include:

• Live rendering — Quickly verify how changes look without leaving the editor
• Server selection & auth — Choose servers and authorize requests where applicable
• Try it out / Test request — 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.