You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
5
6
</p>
6
-
<br>
7
-
<h1>Launching Soon!</h2>
8
-
<p>
9
-
SpecLynx OpenAPI Toolkit will be available during August 2025! Join our <strong><ahref="https://speclynx.com?ref=github-waitlist">waitlist</a></strong> to get early access to SpecLynx in August 2025.
10
-
</p>
11
7
</div>
12
8
13
9
<br>
@@ -24,14 +20,244 @@ Get full YAML/JSON autocompletion, inline documentation hints, validation, linti
24
20
25
21
### One-Click Tooling
26
22
27
-
-Quick Starts & Conversions
28
-
-Reformat & Reorder
23
+
-Powered by a powerful [Language Server](https://microsoft.github.io/language-server-protocol/)
24
+
-JSON Schema Validation
29
25
- Semantic Validation & Linting
30
-
- Breaking change detection
26
+
- Spectral Validation & Linting
27
+
- OpenAPI Description dereferencing
31
28
- Workspace-Wide Operations
32
29
33
30
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.
34
31
35
32
### Built by Veterans
36
33
37
34
SpecLynx OpenAPI Toolkit is crafted by industry veterans, [Vladimír Gorej](https://vladimirgorej.com) and [Francesco Tumanischvili](https://github.com/frantuma), 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.
35
+
36
+
## What is it?
37
+
38
+
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.
39
+
40
+
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.
41
+
42
+
We are actively expanding the feature set and fixing bugs; this documentation will be updated accordingly. 
43
+
44
+
## Capabilities
45
+
46
+
### Editor
47
+
48
+
#### Foreword
49
+
50
+
**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).
51
+
52
+
**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](https://vscode.dev/), [github.dev](https://github.dev/), and [GitHub Codespaces](https://github.com/features/codespaces). It is one of the few extensions that deliver advanced OpenAPI editing and validation/linting in the web environment. 
61
+
62
+
#### In-context OpenAPI Documentation (hover)
63
+
64
+
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. 
70
+
71
+
#### Completion / Suggestions
72
+
73
+
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. 
74
+
75
+
##### Completion docs
76
+
77
+
Each completion item includes full documentation (the same content shown in hover).
78
+
**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 
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.
143
+
***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.
144
+
***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).
145
+
***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. 
146
+
147
+
##### Validation/Linting modes
148
+
149
+
OpenAPI Toolkit supports three modes, which you can combine:
150
+
151
+
1.**JSON Schema validation** — Standard validation based on OpenAPI JSON Schemas
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. 
160
+
161
+
##### Spectral validation/linting
162
+
163
+
To enable Spectral-based checks:
164
+
165
+
1. Enable **Apply Spectral Validation** in the extension settings.
166
+
2. Provide a ruleset by either:
167
+
**(a)** adding a `.spectral.json`, `.spectral.yaml`, or `.spectral.yml` at the root of your workspace, **or**
168
+
**(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).
169
+
170
+
Refer to the [Spectral documentation](https://docs.stoplight.io/docs/spectral/) for ruleset format details. 
1. Enable **Apply Semantic Linting** in the extension settings.
187
+
2. Provide a ruleset by either:
188
+
**(a)** adding a rules file at the workspace root named `.speclynx.json`, `.speclynx.yaml`, `.speclynx.yml` (or without the leading dot), **or**
189
+
**(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). 
190
+
191
+
##### Semantic linting rules (overview)
192
+
193
+
Semantic lint rules are defined in JSON or YAML. A ruleset typically includes:
194
+
195
+
***Rule ID** and **description/message**
196
+
***Severity** (e.g., error, warning, info)
197
+
***Target selector**: a semantic **element type** (e.g., `operation`, `schema`, `parameter`, etc.) and/or a **JSONPath** for precise targeting
198
+
***Condition(s)** to evaluate (e.g., required fields, naming patterns, min/max constraints)
199
+
***Optional fixes** or suggestions (when applicable)
0 commit comments