Buggy API OpenAPI Files
Download an OpenAPI JSON file to use in your REST Client.
This is our default openapi.json file which has standard validation and is in v3.1 format.
File Download Links
OpenAPI JSON files are available in specific OpenAPI versions.
We offer five different styles of each OpenAPI version:
- standard validation - the normal file for using the API as intended, with supported routes and the usual validation rules.
- strong schemas - keeps the normal API surface but adds more explicit schema detail for tools that benefit from stronger request and response shapes.
- operation parameters - keeps the normal schema style but repeats path parameters on each operation for tools that do not fully process path-level parameters.
- strong schemas + operation parameters - combines stronger schemas with operation-level path parameters.
- less validation - a more permissive testing file that relaxes constraints and documents more method/status possibilities.
We've created the different validation and parameter style files for v3.0, v3.1 and v3.2.
- OpenAPI v 3.0 JSON
- OpenAPI v 3.1 JSON
- OpenAPI v 3.2 JSON
Open OpenAPI 3.2 In Online UIs
Tool support for OpenAPI 3.2 is still emerging, so these links help compare how each UI handles the same file.
Standard validation
Open the user-facing Buggy API OpenAPI 3.2 file.
Open in Swagger Open in OpenAPI Explorer Open in Scalar Open in Stoplight Elements Open in Zudoku Open in Redoc
Strong schemas
Open Buggy API OpenAPI 3.2 with explicit schema types and constraints.
Open in Swagger Open in OpenAPI Explorer Open in Scalar Open in Stoplight Elements Open in Zudoku Open in Redoc
Operation parameters
Open Buggy API OpenAPI 3.2 with path parameters repeated on each operation.
Open in Swagger Open in OpenAPI Explorer Open in Scalar Open in Stoplight Elements Open in Zudoku Open in Redoc
Strong schemas + operation parameters
Open Buggy API OpenAPI 3.2 with both stronger schemas and operation-level path parameters.
Open in Swagger Open in OpenAPI Explorer Open in Scalar Open in Stoplight Elements Open in Zudoku Open in Redoc
Less validation
Open the more permissive Buggy API OpenAPI 3.2 file for testing edge cases.
Open in Swagger Open in OpenAPI Explorer Open in Scalar Open in Stoplight Elements Open in Zudoku Open in Redoc
The API is intentionally buggy by default. Start the app with -shopbugs=none when you want the clean business rules for comparison.
About Buggy API's Normal OpenAPI File
The Normal OpenAPI File is the best starting point when you want to use the API as intended.
It lists the supported endpoints and includes the normal validation rules for parameters and payloads. When this file is loaded into a Swagger UI generation application it makes it easy to use the API, while still keeping the client inside the expected contract.
About Buggy API's Strong Schemas OpenAPI File
The Strong Schemas OpenAPI File keeps the same API surface as the normal file, but adds more explicit schema detail.
Use it when your tools make better choices from stronger request and response shapes, or when you want a stricter generated client or schema-aware test tool.
About Buggy API's Operation Parameters OpenAPI File
The Operation Parameters OpenAPI File keeps the normal schema style but repeats path parameters on each operation.
Use it with OpenAPI tools that do not fully process shared path-level parameters, or when generated client code is clearer with the parameters declared directly on each operation.
About Buggy API's Strong Schemas + Operation Parameters OpenAPI File
The Strong Schemas + Operation Parameters OpenAPI File combines the stronger schema detail with operation-level path parameters.
Use it when a tool benefits from both stricter schemas and operation-level path parameter declarations.
About Buggy API's Less Validation OpenAPI File
The Less Validation OpenAPI File is intended for testing.
It relaxes parameter constraints and documents more method/status possibilities, including methods that are not available for normal use.
This makes it possible to use Swagger UI applications to test more extreme situations because the client is less likely to block the request before it reaches the server.