- Custom Rulesets: Create custom rules to lint JSON or YAML objects
- Ready-to-use Rulesets: Validate and lint OpenAPI v2 & v3.x and AsyncAPI Documents
- API Style Guides: Automated API Style Guides using rulesets improve consistency across all your APIs
- Ready-to-use Functions: Built-in set of functions to help create custom rules. Functions include pattern checks, parameter checks, alphabetical ordering, a specified number of characters, provided keys are present in an object, etc.
- Custom Functions: Create custom functions for advanced use cases
- 🧰 Installation
- 💻 Usage
- 📖 Documentation
- ℹ️ Support
- 🌎 Real-World Rulesets
- ⚙️ Integrations
- 👏 Contributing
- 🌲 Sponsor Spectral by Planting a Tree
The easiest way to install spectral is to use either npm:
npm install -g @stoplight/spectral-cliOr yarn:
yarn global add @stoplight/spectral-cli
There are also additional installation options.
Spectral, being a generic YAML/JSON linter, needs a ruleset to lint files. A ruleset is a JSON, YAML, or JavaScript/TypeScript file (often the file is called .spectral.yaml for a YAML ruleset) that contains a collection of rules, which can be used to lint other JSON or YAML files such as an API description.
To get started, run this command in your terminal to create a .spectral.yaml file that uses the Spectral predefined rulesets based on OpenAPI or AsyncAPI:
echo 'extends: ["spectral:oas", "spectral:asyncapi"]' > .spectral.yamlIf you would like to create your own rules, check out the Custom Rulesets page.
Use this command if you have a ruleset file in the same directory as the documents you are linting:
spectral lint myapifile.yamlUse this command to lint with a custom ruleset, or one that's located in a different directory than the documents being linted:
spectral lint myapifile.yaml --ruleset myruleset.yaml- Documentation
- Getting Started - The basics of Spectral.
- Rulesets - Understand the structure of a ruleset so you can tweak and make your own rules.
Once you've had a look through the getting started material, some of these guides can help you become a power user.
- Different Workflows - When and where should you use Spectral? Editors, Git hooks, continuous integration, GitHub Actions, wherever you like!
- Using the command-line interface - Quickest way to get going with Spectral is in the CLI.
- Using the JavaScript API - Access the raw power of Spectral via the JS, or hey, TypeScript if you want.
- Custom Rulesets - Need something more than the core rulesets provide? Fancy building your own API Style Guide? Learn how to create a custom ruleset.
- Custom Functions - Handle more advanced rules, by writing a little JavaScript/TypeScript and calling it as a function.
If you need help using Spectral or have any questions, you can use GitHub Discussions, or visit the Stoplight Community Discord. These communities are a great place to share your rulesets, or show off tools that use Spectral.
If you have a bug or feature request, create an issue for it.
Stoplight has a set of Spectral rulesets that were created to help users get started with Stoplight's Style Guides. You can find them on API Stylebook, and you can download the source Spectral file by selecting a style guide on the project sidebar and selecting Export -> Spectral File(s) on the top-right. A few noteworthy style guides are:
- OWASP Top 10 - Set of rules to enforce OWASP security guidelines.
- URL Style Guidelines - Set of rules to help developers make better and consistent endpoints.
- Documentation - Scan an OpenAPI description to make sure you're leveraging enough of its features to help documentation tools like Stoplight Elements, ReDoc, and Swagger UI build the best quality API Reference Documentation possible.
There are also rulesets created by many companies to improve their APIs. You can use these as is to lint your OpenAPI descriptions, or use these as a reference to learn more about what rules you would want in your own ruleset:
- Adidas - Adidas were one of the first companies to release their API Style Guide in a written guide and a Spectral ruleset. Lots of good rules to try in here.
- APIs You Won't Hate - An opinionated collection of rules based on advice in the APIs You Won't Hate community.
- Azure - Ruleset and complimentary style guide for creating OpenAPI 2 or 3 definitions of Azure services.
- Box - Lots of Custom Functions being used to enforce good practices that the Box API governance folks are interested in.
- DigitalOcean - Keeping their OpenAPI nice and tidy, enforcing use of
$ref(probably to minimize conflicts), naming conventions for Operation IDs, and all sorts of other handy OpenAPI tips. - Tranascom - Don't even think about using anything other than
application/json. - Zalando - Based on Zalando's RESTFUL API Guidelines, covers a wide-range of API topics such as versioning standards, property naming standards, the default format for request/response properties, and more.
Check out some additional style guides here:
- GitHub Action - Lints documents in your repo, built by Vincenzo Chianese.
- JetBrains Plugin - Automatic linting of your OpenAPI specifications and highlighting in your editor.
- Stoplight Studio - Uses Spectral to validate and lint OpenAPI documents.
- VS Code Spectral Extension - All the power of Spectral without leaving VS Code.
If you're using Spectral for an interesting use case, contact Stoplight for a case study. 🎉
If you are interested in contributing to Spectral, check out CONTRIBUTING.md.
- Mike Ralphson for kicking off the Spectral CLI and his work on Speccy
- Jamund Ferguson for JUnit formatter
- Sindre Sorhus for Stylish formatter
- Ava Thorn for the Pretty formatter
- Julian Laval for HTML formatter
- @nulltoken for a whole bunch of amazing features
Spectral is 100% free and open-source, under Apache License 2.0.
If you would like to thank Stoplight for creating Spectral, buy the world a tree.