# API Genie

> API Genie is a command-line toolkit for API-first development. `apigenie` lints, formats, diffs, bundles, converts and translates OpenAPI 3.x, Swagger 2.0, AsyncAPI, Protobuf and GraphQL files, and contract-tests live APIs; `apigenie-generator` generates clients, servers and documentation for TypeScript, Python, Go, Java, C# and Elixir; `apigenie-server` serves mocks and validating proxies for HTTP, WebSocket, MQTT, gRPC and GraphQL.

Every documentation page below is plain Markdown; drop the `.md` suffix for the HTML page.
All of it in one file: https://apigenie.pl/llms-full.txt

- [Quickstart](https://apigenie.pl/docs/quickstart): install API Genie and run the first commands for an existing API, a new API, or a set of APIs to keep consistent.
- [Downloads](https://apigenie.pl/downloads): install with Docker (`mykulyak/apigenie`), Homebrew (`brew install mykulyak/apigenie/apigenie`), npm (`npx @mykulyak/api-genie`) or a binary for macOS, Linux and Windows.
- [CLI](https://apigenie.pl/tools/cli): `apigenie` lints, formats, diffs, bundles, converts and contract-tests OpenAPI, Swagger 2.0, AsyncAPI, Protobuf and GraphQL files.
- [Generator](https://apigenie.pl/tools/generator): `apigenie-generator` generates clients, servers, documentation sites, test data and Zod schemas in TypeScript, Java, Go, Python, C# and Elixir.
- [Server](https://apigenie.pl/tools/server): `apigenie-server` mocks OpenAPI, AsyncAPI, gRPC and GraphQL APIs and contract-tests real ones as a validating proxy.
- [Catalog](https://apigenie.pl/tools/catalog): `apigenie-catalog` lists the API specifications of a Git repository and records their names and owners.
- [Editor](https://apigenie.pl/tools/editor): a form-based editor for OpenAPI and AsyncAPI that keeps files byte for byte; in the browser now, on the desktop and in VS Code from 1.0.0.
- [Doc components](https://apigenie.pl/tools/doc-components): `apg-*` custom elements that document OpenAPI, Swagger 2.0, AsyncAPI, Protobuf and GraphQL APIs.
- [Use cases](https://apigenie.pl/use-cases): what API Genie does, one page per job: [Lint and format](https://apigenie.pl/use-cases/lint-and-format), [Catch breaking changes](https://apigenie.pl/use-cases/breaking-changes), [Generate code](https://apigenie.pl/use-cases/code-generation), [Mock and test](https://apigenie.pl/use-cases/mock-and-test), [Publish API docs](https://apigenie.pl/use-cases/api-docs), [Edit visually](https://apigenie.pl/use-cases/visual-editing), [Catalog your APIs](https://apigenie.pl/use-cases/api-catalog), [Work with AI agents](https://apigenie.pl/use-cases/ai-agents).
- [Safety](https://apigenie.pl/safety): how the C++ code is kept safe and tested.
- [Credits and licenses](https://apigenie.pl/credits): the open source libraries API Genie uses.
- [Changelog](https://apigenie.pl/changelog): what changed in each release of the CLI.

## How-to guides

- [Lint and format API descriptions](https://apigenie.pl/docs/guides/lint-and-format-api-descriptions.md): Give every API description of a repository the same rules and the same style, locally and in every pull request.
- [Catch breaking changes in CI](https://apigenie.pl/docs/guides/catch-breaking-changes-in-ci.md): Fail the pull request that would break your clients, retire old operations on a schedule, and keep a changelog from git.
- [Generate a client and a server](https://apigenie.pl/docs/guides/generate-a-client-and-a-server.md): Generate a typed client and a server from one OpenAPI document, keep your code out of the generated files, and regenerate in CI.
- [Mock and contract-test an API](https://apigenie.pl/docs/guides/mock-and-contract-test-an-api.md): Serve an API from its contract before the server exists, then check the real server against the contract in CI.
- [Publish API documentation](https://apigenie.pl/docs/guides/publish-api-documentation.md): Build a documentation site from your API descriptions, translate it, add the changelog of each API, or put a reference into a page of your own.
- [Edit an API in forms](https://apigenie.pl/docs/guides/edit-an-api-in-forms.md): Open a folder of OpenAPI or AsyncAPI files in the editor, change them in forms, and review the change like any other.
- [Catalog the APIs of a repository](https://apigenie.pl/docs/guides/catalog-the-apis-of-a-repository.md): List every API specification of a repository, give each a stable name and an owner, and keep the catalog current in CI.
- [Work with AI agents](https://apigenie.pl/docs/guides/work-with-ai-agents.md): Put the linter, the diff and the formatter in a coding agent's loop, so that what it changes in a contract is checked the way a person's change is.

## Reference

- [Overview](https://apigenie.pl/docs/reference/cli/overview.md): API Genie CLI streamlines Web API development by providing a command-line interface for managing, testing and generating artifacts from OpenAPI, Swagger, AsyncAPI, Protobuf and GraphQL descriptions.
- [Configuration](https://apigenie.pl/docs/reference/cli/configuration.md): Most of API Genie CLI commands use configuration files. This file stores default parameters for API Genie CLI commands specific to your organization.
- [Formats](https://apigenie.pl/docs/reference/cli/formats.md): API Genie follows the OpenAPI format registry, the list of `format` values the OpenAPI Initiative keeps, with the JSON types each applies to. The same list drives every part of API Genie (docs/adrs/166):
- [faker](https://apigenie.pl/docs/reference/cli/faker.md): API Genie makes realistic values (names, emails, addresses, IBANs, dates...) with its own faker library. Its providers are named like those of faker.js (`person.firstName`, `internet.email`) and are used by:
- [Compatibility](https://apigenie.pl/docs/reference/cli/compatibility.md): Scripts, CI jobs, Dockerfiles and dashboards call API Genie and read what it writes. This page says what they can rely on from one release to the next.
- [GitHub Action](https://apigenie.pl/docs/ci/github-action.md): The API Genie GitHub Action installs the CLI on GitHub Actions runners and lints, checks the formatting of, or diffs OpenAPI, Swagger 2.0, AsyncAPI, Protobuf and GraphQL files. Issues and changes are shown as annotations on the files of a pull request, and a report is added to the job summary. The action is published on the GitHub Marketplace as `mykulyak/api-genie-action`; its source and its releases are in mykulyak/api-genie-action.
- [Commands](https://apigenie.pl/docs/reference/cli.md): `apigenie` is the API Genie command-line interface. Each command works on one or more API descriptions: OpenAPI, Swagger 2.0, AsyncAPI, Protobuf or GraphQL files.
- [bundle](https://apigenie.pl/docs/reference/cli/bundle.md): Bundles an OpenAPI, Swagger or AsyncAPI schema and the files it references, or a Protobuf (`.proto`) file and the files it imports, into a single file.
- [changelog](https://apigenie.pl/docs/reference/cli/changelog.md): Builds the changelog of an OpenAPI, Swagger, AsyncAPI, Protobuf or GraphQL file from its Git history.
- [config](https://apigenie.pl/docs/reference/cli/config.md): Prints the effective configuration, checks a configuration file, and prints the JSON Schema of the configuration file.
- [convert](https://apigenie.pl/docs/reference/cli/convert.md): Convert a Swagger 2.0 document to OpenAPI 3.2, a WSDL 1.1 document to OpenAPI 3.1, or a JSON Schema document of a newer draft to draft-07, draft-04 or the Schema Object dialect of OpenAPI 3.0.
- [credits](https://apigenie.pl/docs/reference/cli/credits.md): Displays credits for 3rd party libraries used by API Genie.
- [diff](https://apigenie.pl/docs/reference/cli/diff.md): Compares two versions of an OpenAPI, Swagger 2.0 or AsyncAPI schema, of a Protobuf (`.proto`) file, or of a GraphQL schema, and reports the changes and their severity.
- [evolve](https://apigenie.pl/docs/reference/cli/evolve.md): Plans safe API changes: `evolve plan` splits the breaking changes between two OpenAPI documents into an expand wave (deprecate, add next to) and a contract wave (remove), writes the wave documents and the plan, and proves the plan with `diff`.
- [format](https://apigenie.pl/docs/reference/cli/format.md): Formats JSON and YAML files containing OpenAPI, Swagger 2.0 or AsyncAPI schemas, Protobuf (`.proto`) files and GraphQL (`.graphql`, `.graphqls`, `.gql`) files.
- [i18n](https://apigenie.pl/docs/reference/cli/i18n.md): Extracts texts for localization from OpenAPI, Swagger 2.0 and AsyncAPI specifications and Protobuf and GraphQL files, checks and updates their translations, and applies them. All subcommands work on all five: `i18n extract` writes the texts as a key-value file, `i18n check` tells whether a translation file is complete, `i18n sync` updates one after the document changed, and `i18n apply` puts the translated values back.
- [license](https://apigenie.pl/docs/reference/cli/license.md): Displays license information of API Genie and 3rd party libraries it uses.
- [lint](https://apigenie.pl/docs/reference/cli/lint.md): Detects stylistic and structural issues in OpenAPI, Swagger 2.0 and AsyncAPI documents, Protobuf (`.proto`) files and GraphQL schemas, improving their quality.
- [overlay](https://apigenie.pl/docs/reference/cli/overlay.md): Applies OpenAPI Overlays to an OpenAPI schema, or to any JSON or YAML document.
- [test](https://apigenie.pl/docs/reference/cli/test.md): Runs the requests of `.http` files and requests generated from an OpenAPI or AsyncAPI document, a GraphQL schema or a `.proto` file against a live server, checks their assertions and scripts, and validates every request, response and message against the document or the schema with the checks of the validating proxy. HTTP requests are checked against an OpenAPI document, GraphQL requests against a GraphQL schema, `GRPC` requests against a `.proto` file, and WebSocket and MQTT requests and the requests of HTTP channels against an AsyncAPI document.
- [apigenie-generator](https://apigenie.pl/docs/reference/generator.md): `apigenie-generator` generates code and data from an OpenAPI or AsyncAPI document, servers from a GraphQL schema, gRPC code from a Protobuf file set, documentation sites from OpenAPI, Swagger, AsyncAPI, GraphQL and Protobuf files, and validation schemas from JSON Schemas. It is a separate executable, installed next to `apigenie` by every package, the npm package and the Docker image (run it there with `docker run --entrypoint apigenie-generator mykulyak/apigenie ...`). Before 0.9.0 the generators were the `apigenie generate` command: `apigenie generate client fetch ...` is now `apigenie-generator client fetch ...`, with the same options and configuration.
- [docs](https://apigenie.pl/docs/reference/generator/docs.md): Generate a documentation site from OpenAPI, Swagger 2.0, AsyncAPI, GraphQL and Protobuf files, several at once.
- [data](https://apigenie.pl/docs/reference/generator/data.md): Generate example data for a schema of an OpenAPI document. The command is experimental.
- [schema zod](https://apigenie.pl/docs/reference/generator/schema-zod.md): Generate Zod (v4) schemas, with their TypeScript types, from JSON Schemas.
- [client csharp](https://apigenie.pl/docs/reference/generator/client-csharp.md): Generate a C# client of an OpenAPI document, built on `HttpClient` and `System.Text.Json`, for .NET 8 (or 9 and 10).
- [client elixir](https://apigenie.pl/docs/reference/generator/client-elixir.md): Generate an Elixir client on Req from an OpenAPI document.
- [client fetch](https://apigenie.pl/docs/reference/generator/client-fetch.md): Generate a TypeScript client for the Fetch API from an OpenAPI document.
- [client go](https://apigenie.pl/docs/reference/generator/client-go.md): Generate a Go client for the `net/http` package of Go 1.22 from an OpenAPI document.
- [client java](https://apigenie.pl/docs/reference/generator/client-java.md): Generate a Java client of an OpenAPI document: a Maven project using Spring's `RestClient` (the default) or `RestTemplate`, Spring Cloud OpenFeign interfaces, or Spring HTTP interfaces.
- [client python](https://apigenie.pl/docs/reference/generator/client-python.md): Generate a Python client of an OpenAPI document, built on httpx and Pydantic 2.
- [server aspnet](https://apigenie.pl/docs/reference/generator/server-aspnet.md): Generate an ASP.NET Core server in C#, built on Minimal APIs.
- [server express](https://apigenie.pl/docs/reference/generator/server-express.md): Generate an Express server stub in TypeScript from an OpenAPI document.
- [server fastapi](https://apigenie.pl/docs/reference/generator/server-fastapi.md): Generate a Python FastAPI server from an OpenAPI document.
- [server go](https://apigenie.pl/docs/reference/generator/server-go.md): Generate a Go server for the `net/http` router of Go 1.22 from an OpenAPI document.
- [server mcp](https://apigenie.pl/docs/reference/generator/server-mcp.md): Generate a Model Context Protocol server in TypeScript from an OpenAPI document, so that AI agents call the API through typed tools.
- [server orpc](https://apigenie.pl/docs/reference/generator/server-orpc.md): Generate a TypeScript server based on oRPC from an OpenAPI document.
- [server phoenix](https://apigenie.pl/docs/reference/generator/server-phoenix.md): Generate a Phoenix 1.7 application from an OpenAPI document.
- [server spring](https://apigenie.pl/docs/reference/generator/server-spring.md): Generate a Spring Boot server, or Spring Cloud / HTTP interface clients, in Java.
- [client csharp (AsyncAPI)](https://apigenie.pl/docs/reference/generator/client-csharp-asyncapi.md): Generate a C# Kafka client library for the Kafka channels of an AsyncAPI document.
- [client elixir (AsyncAPI)](https://apigenie.pl/docs/reference/generator/client-elixir-asyncapi.md): Generate an Elixir client library of the WebSocket and Kafka channels of an AsyncAPI document.
- [client go (AsyncAPI)](https://apigenie.pl/docs/reference/generator/client-go-asyncapi.md): Generate a Go Kafka client package for the Kafka channels of an AsyncAPI document.
- [client java (AsyncAPI)](https://apigenie.pl/docs/reference/generator/client-java-asyncapi.md): Generate a Java Kafka client library for the Kafka channels of an AsyncAPI document.
- [client kafkajs](https://apigenie.pl/docs/reference/generator/client-kafkajs.md): Generate a TypeScript (Node.js) Kafka client of an AsyncAPI document, on KafkaJS.
- [client python (AsyncAPI)](https://apigenie.pl/docs/reference/generator/client-python-asyncapi.md): Generate a Python asyncio Kafka client package for the Kafka channels of an AsyncAPI document.
- [client ws](https://apigenie.pl/docs/reference/generator/client-ws.md): Generate a TypeScript client of the WebSocket channels of an AsyncAPI document.
- [server aspnet (AsyncAPI)](https://apigenie.pl/docs/reference/generator/server-aspnet-asyncapi.md): Generate an ASP.NET Core application of the Kafka channels of an AsyncAPI document.
- [server faststream](https://apigenie.pl/docs/reference/generator/server-faststream.md): Generate a Python FastStream application of the Kafka, AMQP (RabbitMQ) and MQTT channels of an AsyncAPI document.
- [server go (AsyncAPI)](https://apigenie.pl/docs/reference/generator/server-go-asyncapi.md): Generate a Go Kafka application of the Kafka channels of an AsyncAPI document.
- [server kafkajs](https://apigenie.pl/docs/reference/generator/server-kafkajs.md): Generate a TypeScript (Node.js) Kafka application of an AsyncAPI document, on KafkaJS.
- [server phoenix (AsyncAPI)](https://apigenie.pl/docs/reference/generator/server-phoenix-asyncapi.md): Generate a Phoenix application of the WebSocket and Kafka channels of an AsyncAPI document.
- [server spring (AsyncAPI)](https://apigenie.pl/docs/reference/generator/server-spring-asyncapi.md): Generate a Spring Boot application of the Kafka channels of an AsyncAPI document.
- [server ws](https://apigenie.pl/docs/reference/generator/server-ws.md): Generate a TypeScript (Node.js) server of the WebSocket channels of an AsyncAPI document.
- [client elixir (Protobuf)](https://apigenie.pl/docs/reference/generator/client-elixir-protobuf.md): Generate an Elixir gRPC client on elixir-grpc from a `.proto` file and the files it imports.
- [server elixir-grpc](https://apigenie.pl/docs/reference/generator/server-elixir-grpc.md): Generate an Elixir gRPC server on elixir-grpc from a `.proto` file and the files it imports.
- [server absinthe](https://apigenie.pl/docs/reference/generator/server-absinthe.md): Generate an Absinthe server from a GraphQL schema (SDL).
- [server](https://apigenie.pl/docs/reference/server.md): `apigenie-server` serves an OpenAPI 3.0, 3.1 or 3.2 document (or a Swagger 2.0 one, see Swagger 2.0 documents) as a mock API, the channels of an AsyncAPI 3.x document over WebSocket, HTTP and MQTT, the gRPC services of a `.proto` file, or a GraphQL schema as a GraphQL endpoint with subscriptions. It answers with the document's examples, with stubs, or with data generated from its schemas, validates requests, responses and messages, logs every exchange, and can make the network slow or unreliable on purpose. In front of a real server (`--proxy-to`) it becomes a validating proxy that contract-tests the server's traffic against the OpenAPI or Swagger document, the GraphQL schema, the AsyncAPI document (WebSocket, MQTT and HTTP channels) or the `.proto` file, with coverage and JSON or JUnit reports. It is installed next to `apigenie` by every package (archives, `.deb`, `.rpm`, npm, Homebrew) and has a Docker image of its own.
- [catalog](https://apigenie.pl/docs/reference/catalog.md): `apigenie-catalog` lists the API specifications of a repository, and records their names and owners in the configuration file. It is installed next to `apigenie` by every archive and package, npm and Homebrew; `apigenie catalog ...` prints the `apigenie-catalog` command to run instead.
- [The editor's hosts](https://apigenie.pl/docs/reference/editor/hosts.md): The API Genie editor edits OpenAPI 3.0, OpenAPI 3.1 and AsyncAPI 3.0 files in forms, on three hosts, with the same page in each:

## OpenAPI linter rules

- [audience-defined](https://apigenie.pl/docs/linter/openapi/rules/audience-defined.md): This rule checks whether an OpenAPI schema defines its target audience.
- [contact-defined](https://apigenie.pl/docs/linter/openapi/rules/contact-defined.md): This rule checks whether the contact object is present in an OpenAPI schema.
- [id-defined](https://apigenie.pl/docs/linter/openapi/rules/id-defined.md): This rule checks whether the `#/info/x-id` attribute is present in an OpenAPI schema and if it's a valid UUID.
- [info-defined](https://apigenie.pl/docs/linter/openapi/rules/info-defined.md): This rule checks whether the info object is present in an OpenAPI schema and if it contains the `summary`, `description`, and `version` fields.
- [json-api/content-type](https://apigenie.pl/docs/linter/openapi/rules/json-api-content-type.md): This rule ensures that every request and response in an OpenAPI schema provides the `application/vnd.api+json` media type.
- [json-api/resource-type-unique](https://apigenie.pl/docs/linter/openapi/rules/json-api-resource-type-unique.md): This rule ensures that all resource schemas in a JSON:API have unique resource IDs.
- [json-api/schema-validation](https://apigenie.pl/docs/linter/openapi/rules/json-api-schema-validation.md): This rule ensures that request and response documents in a JSON:API conform to the JSON:API specification.
- [json-schema-validation](https://apigenie.pl/docs/linter/openapi/rules/json-schema-validation.md): Validates OpenAPI 3.0 schema against JSON meta-schema.
- [license-defined](https://apigenie.pl/docs/linter/openapi/rules/license-defined.md): This rule checks whether the licensing information is present in an OpenAPI schema.
- [no-content-response-defined](https://apigenie.pl/docs/linter/openapi/rules/no-content-response-defined.md): This rule ensures that responses for HTTP status 204 do not define their response bodies.
- [openapi-json-schema-validation](https://apigenie.pl/docs/linter/openapi/rules/openapi-json-schema-validation.md): This rule validates an OpenAPI specification against the OpenAPI 3.x JSON schema.
- [operation-description-defined](https://apigenie.pl/docs/linter/openapi/rules/operation-description-defined.md): This rule checks each operation's description in an OpenAPI schema and warns if the description is empty.
- [operation-document-not-primitive](https://apigenie.pl/docs/linter/openapi/rules/operation-document-not-primitive.md): Check operation responses and warn if they are defined as primitive values.
- [operation-id-defined](https://apigenie.pl/docs/linter/openapi/rules/operation-id-defined.md): This rule checks each operation defined in an OpenAPI schema and warns if operation IDs are missing or empty.
- [operation-id-unique](https://apigenie.pl/docs/linter/openapi/rules/operation-id-unique.md): This rule checks whether operations defined in an OpenAPI schema have unique IDs.
- [operation-rate-limiting-defined](https://apigenie.pl/docs/linter/openapi/rules/operation-rate-limiting-defined.md): Warn if operation does not define rate limiting headers.
- [operation-security-defined](https://apigenie.pl/docs/linter/openapi/rules/operation-security-defined.md): Warn if OpenAPI operation does not have any sequrity requirements.
- [operation-success-response](https://apigenie.pl/docs/linter/openapi/rules/operation-success-response.md): This rule warns when an operation in an OpenAPI schema does not define any success response, i.e., those corresponding to 2xx or 3xx codes.
- [operation-tags-defined](https://apigenie.pl/docs/linter/openapi/rules/operation-tags-defined.md): This rule checks each operations' tags in an OpenAPI schema and warns if any of them are empty lists.
- [parameter-description-defined](https://apigenie.pl/docs/linter/openapi/rules/parameter-description-defined.md): This rule checks every parameter defined in an OpenAPI schema and warns when a its description is empty or missing.
- [parameter-naming](https://apigenie.pl/docs/linter/openapi/rules/parameter-naming.md): This rule checks all parameters in an OpenAPI schema and warns if they do not adhere to the specified naming convention.
- [parameters-unique](https://apigenie.pl/docs/linter/openapi/rules/parameters-unique.md): Check parameters of operations and path items and warn if they have duplicate parameters.
- [patch-request-body-partial](https://apigenie.pl/docs/linter/openapi/rules/patch-request-body-partial.md): This rule checks that `PATCH` request bodies do not require properties.
- [path-parameters-defined](https://apigenie.pl/docs/linter/openapi/rules/path-parameters-defined.md): This rule ensures that for all parameter placeholders defined in path item URLs, there are path parameters defined in corresponding path items or their operations.
- [path-parameters-on-items](https://apigenie.pl/docs/linter/openapi/rules/path-parameters-on-items.md): This rule ensures that all path parameters are defined on path item levels, and not on the operation level.
- [paths-max-count](https://apigenie.pl/docs/linter/openapi/rules/paths-max-count.md): This rule ensures that an API does not define too many path items.
- [paths-max-depth](https://apigenie.pl/docs/linter/openapi/rules/paths-max-depth.md): This rule ensures that path item URLs do not contain too many segments.
- [paths-sorted](https://apigenie.pl/docs/linter/openapi/rules/paths-sorted.md): This rule checks URLs of path items defined in an OpenAPI schema, and warns if they are not placed in alphabetical order.
- [paths-unique](https://apigenie.pl/docs/linter/openapi/rules/paths-unique.md): This rule checks whether URLs of path items are unique.
- [paths-well-formed](https://apigenie.pl/docs/linter/openapi/rules/paths-well-formed.md): This rule checks whether URLs of path items are well-formed.
- [privacy/no-credentials-in-url](https://apigenie.pl/docs/linter/openapi/rules/privacy-no-credentials-in-url.md): This rule reports passwords, tokens, API keys and other credentials passed in path or query parameters, and API keys that a security scheme sends in the query string.
- [privacy/no-personal-data-in-url](https://apigenie.pl/docs/linter/openapi/rules/privacy-no-personal-data-in-url.md): This rule reports personal data, such as e-mail addresses, names, dates of birth, phone numbers and national identification numbers, passed in path or query parameters.
- [safe-markdown](https://apigenie.pl/docs/linter/openapi/rules/safe-markdown.md): This rule ensures that markdown strings (mostly descriptions) do not contain unsafe operations like script tags or eval() constructs.
- [schema-conditional-effective](https://apigenie.pl/docs/linter/openapi/rules/schema-conditional-effective.md): This rule checks that `if`, `then` and `else` in schemas have an effect.
- [schema-constraints](https://apigenie.pl/docs/linter/openapi/rules/schema-constraints.md): This rule ensures that schema objects define constraints restricting the size of the underlying data.
- [schema-datetime-suffix](https://apigenie.pl/docs/linter/openapi/rules/schema-datetime-suffix.md): This rule ensures that names of schema properties that represent date-times end with specified suffix.
- [schema-discriminator-defined](https://apigenie.pl/docs/linter/openapi/rules/schema-discriminator-defined.md): This rule ensures that whenever a schema object defines a `oneOf` clause, it also defines a discriminator property.
- [schema-enum-naming](https://apigenie.pl/docs/linter/openapi/rules/schema-enum-naming.md): This rule ensures that all string values defined in `enum` or `const` properties of schema objects adhere to a predefined naming convention.
- [schema-enum-no-duplicates](https://apigenie.pl/docs/linter/openapi/rules/schema-enum-no-duplicates.md): This rule ensures that schema objects do not have duplicate values in their `enum` or `const` properties.
- [schema-enum-types](https://apigenie.pl/docs/linter/openapi/rules/schema-enum-types.md): This rule checks schema objects and warns if allowed schema values (from `enum` and `const` properties) are consistent with schema types (i.e. their type property).
- [schema-example-defined](https://apigenie.pl/docs/linter/openapi/rules/schema-example-defined.md): This rule ensures that all non-trivial schemas have at least one example defined.
- [schema-format-defined](https://apigenie.pl/docs/linter/openapi/rules/schema-format-defined.md): This rule ensures that every schema object that is a string or a number has its format defined.
- [schema-format-deprecated](https://apigenie.pl/docs/linter/openapi/rules/schema-format-deprecated.md): This rule reports the formats which the OpenAPI format registry marks as deprecated, and names what replaces them.
- [schema-format-type-mismatch](https://apigenie.pl/docs/linter/openapi/rules/schema-format-type-mismatch.md): This rule checks all schema objects and warns if any of them have their `type` and `format` properties contradicting each other.
- [schema-format-unknown](https://apigenie.pl/docs/linter/openapi/rules/schema-format-unknown.md): This rule reports a `format` which is neither in the OpenAPI format registry nor declared in `openapi.custom_formats` of the configuration file.
- [schema-keyword-support](https://apigenie.pl/docs/linter/openapi/rules/schema-keyword-support.md): This rule reports schema keywords that the tools consuming the document are unlikely to support, and suggests the rewrite where one exists.
- [schema-no-additional-properties](https://apigenie.pl/docs/linter/openapi/rules/schema-no-additional-properties.md): This rule ensures that schema objects of type "object" explicitly forbid additional properties.
- [schema-no-contradictions](https://apigenie.pl/docs/linter/openapi/rules/schema-no-contradictions.md): This rule reports schemas with contradicting constraints, which reject every value or some of the properties they describe.
- [schema-no-optional-nullable-properties](https://apigenie.pl/docs/linter/openapi/rules/schema-no-optional-nullable-properties.md): This rule disallows schema properties that are both optional and nullable.
- [schema-oneof-no-overlap](https://apigenie.pl/docs/linter/openapi/rules/schema-oneof-no-overlap.md): This rule reports `oneOf` branches that a single value can match.
- [schema-property-naming](https://apigenie.pl/docs/linter/openapi/rules/schema-property-naming.md): This rule checks all schema objects and warns if any of them define properties whose names do not adhere to the specified naming convention.
- [schema-required-properties-defined](https://apigenie.pl/docs/linter/openapi/rules/schema-required-properties-defined.md): This rule checks that every name listed in `required` is defined in `properties`.
- [server-urls](https://apigenie.pl/docs/linter/openapi/rules/server-urls.md): This rule warns if a server defined by an OpenAPI schema uses HTTP protocol while not being from localhost, or uses upper-case letters.
- [servers-defined](https://apigenie.pl/docs/linter/openapi/rules/servers-defined.md): This rule warns if an OpenAPI schema does not define any server.
- [spell-check](https://apigenie.pl/docs/linter/openapi/rules/spell-check.md): This rule checks the spelling of the texts written for humans: titles, summaries and descriptions.
- [standard-media-types](https://apigenie.pl/docs/linter/openapi/rules/standard-media-types.md): This rule checks whether requests and responses use only standard media types.
- [standard-response-codes](https://apigenie.pl/docs/linter/openapi/rules/standard-response-codes.md): This rule checks whether operations define responses for standard HTTP codes only, as described in RFC 9110.
- [standard-response-errors](https://apigenie.pl/docs/linter/openapi/rules/standard-response-errors.md): This rule ensures that bodies for "error" responses are adhere to the same convention.
- [tag-description-defined](https://apigenie.pl/docs/linter/openapi/rules/tag-description-defined.md): This rule checks whether each tag defined in an OpenAPI schema has a meaningful description.
- [tags-sorted](https://apigenie.pl/docs/linter/openapi/rules/tags-sorted.md): This rule checks whether tags defined in an OpenAPI schema are sorted alphabetically according to their names.
- [tags-unique](https://apigenie.pl/docs/linter/openapi/rules/tags-unique.md): This rule checks for schemas that define multiple tags with the same name, considering tag names as case-insensitive.
- [unambiguous-response-codes](https://apigenie.pl/docs/linter/openapi/rules/unambiguous-response-codes.md): This rule checks for operations that define responses for both a generic code (like 2XX) and a specific code in the same range (like 204).
- [unused-request-body](https://apigenie.pl/docs/linter/openapi/rules/unused-request-body.md): This rule checks for operations that normally cannot have a request body (i.e., `GET`, `TRACE`, or `HEAD`), but still define one.
- [unused-shared-component](https://apigenie.pl/docs/linter/openapi/rules/unused-shared-component.md): This rule checks whether all components defined in an OpenAPI schema are used.

## AsyncAPI linter rules

- [audience-defined](https://apigenie.pl/docs/linter/asyncapi/rules/audience-defined.md): This rule checks whether the intended audience of an API is declared in the `#/info/x-audience` extension of an AsyncAPI document.
- [channel-addresses-unique](https://apigenie.pl/docs/linter/asyncapi/rules/channel-addresses-unique.md): This rule checks that no two channels of an AsyncAPI document share the same address, including addresses that differ only by the names of their parameters.
- [channel-parameters-defined](https://apigenie.pl/docs/linter/asyncapi/rules/channel-parameters-defined.md): This rule checks that the parameters used in a channel address are declared in the channel's `parameters` map, and that the map declares no parameters the address does not use.
- [contact-defined](https://apigenie.pl/docs/linter/asyncapi/rules/contact-defined.md): This rule checks whether complete contact information is present in an AsyncAPI document.
- [id-defined](https://apigenie.pl/docs/linter/asyncapi/rules/id-defined.md): This rule checks whether the application identifier (the root `id` field) is present in an AsyncAPI document, and whether its value matches the expected format.
- [info-defined](https://apigenie.pl/docs/linter/asyncapi/rules/info-defined.md): This rule checks whether the info object of an AsyncAPI document provides a description and a version.
- [license-defined](https://apigenie.pl/docs/linter/asyncapi/rules/license-defined.md): This rule checks whether the licensing information is present in an AsyncAPI document.
- [operation-description-defined](https://apigenie.pl/docs/linter/asyncapi/rules/operation-description-defined.md): This rule checks whether every operation of an AsyncAPI document has a meaningful description.
- [operation-security-defined](https://apigenie.pl/docs/linter/asyncapi/rules/operation-security-defined.md): This rule checks whether every operation of an AsyncAPI document is protected by a security requirement.
- [operation-tags-defined](https://apigenie.pl/docs/linter/asyncapi/rules/operation-tags-defined.md): This rule checks whether every operation of an AsyncAPI document has at least one tag assigned.
- [parameter-description-defined](https://apigenie.pl/docs/linter/asyncapi/rules/parameter-description-defined.md): This rule checks whether every channel parameter of an AsyncAPI document has a meaningful description.
- [parameter-naming](https://apigenie.pl/docs/linter/asyncapi/rules/parameter-naming.md): This rule checks all channel parameters in an AsyncAPI document and warns if their names do not adhere to the specified naming convention.
- [safe-markdown](https://apigenie.pl/docs/linter/asyncapi/rules/safe-markdown.md): This rule ensures that Markdown strings (descriptions) do not contain unsafe constructs like script tags or `eval()` calls.
- [schema-constraints](https://apigenie.pl/docs/linter/asyncapi/rules/schema-constraints.md): This rule ensures that schema objects define constraints restricting the size of the underlying data.
- [schema-datetime-suffix](https://apigenie.pl/docs/linter/asyncapi/rules/schema-datetime-suffix.md): This rule ensures that the names of date and time properties end with a common suffix.
- [schema-enum-naming](https://apigenie.pl/docs/linter/asyncapi/rules/schema-enum-naming.md): This rule ensures that all string values defined in the `enum` properties of schema objects adhere to a predefined naming convention.
- [schema-enum-no-duplicates](https://apigenie.pl/docs/linter/asyncapi/rules/schema-enum-no-duplicates.md): This rule ensures that the `enum` lists of schema objects contain no duplicate values.
- [schema-enum-types](https://apigenie.pl/docs/linter/asyncapi/rules/schema-enum-types.md): This rule ensures that the values listed in the `enum` of a schema are allowed by the schema's `type`.
- [schema-example-defined](https://apigenie.pl/docs/linter/asyncapi/rules/schema-example-defined.md): This rule ensures that top-level schemas of an AsyncAPI document provide examples.
- [schema-format-defined](https://apigenie.pl/docs/linter/asyncapi/rules/schema-format-defined.md): This rule ensures that numeric schemas specify the precision of their values with a `format`.
- [schema-format-deprecated](https://apigenie.pl/docs/linter/asyncapi/rules/schema-format-deprecated.md): This rule reports the formats which the OpenAPI format registry marks as deprecated from OpenAPI 3.1, and names what replaces them.
- [schema-format-type-mismatch](https://apigenie.pl/docs/linter/asyncapi/rules/schema-format-type-mismatch.md): This rule ensures that the `format` of a schema is consistent with its `type`.
- [schema-format-unknown](https://apigenie.pl/docs/linter/asyncapi/rules/schema-format-unknown.md): This rule reports a `format` of a AsyncAPI document which is neither in the OpenAPI format registry nor declared in `openapi.custom_formats` of the configuration file.
- [schema-keyword-support](https://apigenie.pl/docs/linter/asyncapi/rules/schema-keyword-support.md): This rule reports schema keywords that the tools consuming the document are unlikely to support, and suggests the rewrite where one exists.
- [schema-no-additional-properties](https://apigenie.pl/docs/linter/asyncapi/rules/schema-no-additional-properties.md): This rule ensures that object schemas explicitly disallow additional properties.
- [schema-property-naming](https://apigenie.pl/docs/linter/asyncapi/rules/schema-property-naming.md): This rule ensures that the names of schema properties adhere to a predefined naming convention.
- [server-hosts](https://apigenie.pl/docs/linter/asyncapi/rules/server-hosts.md): This rule checks that the servers of an AsyncAPI document have well-formed hosts and protocols, and that they use secure protocols.
- [servers-defined](https://apigenie.pl/docs/linter/asyncapi/rules/servers-defined.md): This rule checks whether at least one server is defined in an AsyncAPI document.
- [spell-check](https://apigenie.pl/docs/linter/asyncapi/rules/spell-check.md): This rule checks the spelling of the texts written for humans: titles, summaries and descriptions.
- [standard-media-types](https://apigenie.pl/docs/linter/asyncapi/rules/standard-media-types.md): This rule checks whether messages use only standard media types.
- [tag-description-defined](https://apigenie.pl/docs/linter/asyncapi/rules/tag-description-defined.md): This rule checks whether every tag of an AsyncAPI document has a meaningful description.
- [tags-sorted](https://apigenie.pl/docs/linter/asyncapi/rules/tags-sorted.md): This rule checks whether the tags listed in `info.tags` are sorted by their names.
- [tags-unique](https://apigenie.pl/docs/linter/asyncapi/rules/tags-unique.md): This rule checks whether the names of the tags listed in `info.tags` are unique.
- [unused-shared-component](https://apigenie.pl/docs/linter/asyncapi/rules/unused-shared-component.md): This rule checks whether every shared component of an AsyncAPI document is actually used.

## Swagger 2.0 linter rules

- [audience-defined](https://apigenie.pl/docs/linter/swagger/rules/audience-defined.md): This rule checks whether the intended audience of an API is declared in the `x-audience` extension of the info object of a Swagger 2.0 document.
- [contact-defined](https://apigenie.pl/docs/linter/swagger/rules/contact-defined.md): This rule checks whether complete contact information is present in a Swagger 2.0 document.
- [host-defined](https://apigenie.pl/docs/linter/swagger/rules/host-defined.md): This rule checks whether a Swagger 2.0 document declares the host that serves the API.
- [id-defined](https://apigenie.pl/docs/linter/swagger/rules/id-defined.md): This rule checks whether the info object of a Swagger 2.0 document has an identifier extension (`x-id` by default), and whether its value has the expected format (a UUID by default).
- [info-defined](https://apigenie.pl/docs/linter/swagger/rules/info-defined.md): This rule checks whether the info object of a Swagger 2.0 document provides a description and a version.
- [license-defined](https://apigenie.pl/docs/linter/swagger/rules/license-defined.md): This rule checks whether the licensing information is present in a Swagger 2.0 document.
- [media-types-defined](https://apigenie.pl/docs/linter/swagger/rules/media-types-defined.md): This rule checks whether the operations of a Swagger 2.0 document that send or receive a body declare its media types.
- [no-content-response-defined](https://apigenie.pl/docs/linter/swagger/rules/no-content-response-defined.md): This rule checks whether `204 No Content` responses of a Swagger 2.0 document declare a body.
- [operation-description-defined](https://apigenie.pl/docs/linter/swagger/rules/operation-description-defined.md): This rule checks whether every operation of a Swagger 2.0 document has a meaningful description.
- [operation-id-defined](https://apigenie.pl/docs/linter/swagger/rules/operation-id-defined.md): This rule checks whether every operation of a Swagger 2.0 document has an operation ID.
- [operation-id-unique](https://apigenie.pl/docs/linter/swagger/rules/operation-id-unique.md): This rule checks whether the operation IDs of a Swagger 2.0 document are unique.
- [operation-rate-limiting-defined](https://apigenie.pl/docs/linter/swagger/rules/operation-rate-limiting-defined.md): This rule checks whether the responses of Swagger 2.0 operations declare rate limiting headers.
- [operation-security-defined](https://apigenie.pl/docs/linter/swagger/rules/operation-security-defined.md): This rule checks whether every operation of a Swagger 2.0 document is covered by a security requirement.
- [operation-success-response](https://apigenie.pl/docs/linter/swagger/rules/operation-success-response.md): This rule checks whether every operation of a Swagger 2.0 document declares at least one success response.
- [operation-tags-defined](https://apigenie.pl/docs/linter/swagger/rules/operation-tags-defined.md): This rule checks whether every operation of a Swagger 2.0 document has at least one tag.
- [parameter-description-defined](https://apigenie.pl/docs/linter/swagger/rules/parameter-description-defined.md): This rule checks whether every parameter of a Swagger 2.0 document has a meaningful description.
- [parameter-naming](https://apigenie.pl/docs/linter/swagger/rules/parameter-naming.md): This rule checks whether parameter names of a Swagger 2.0 document follow a naming convention.
- [parameters-unique](https://apigenie.pl/docs/linter/swagger/rules/parameters-unique.md): This rule checks whether the parameter lists of a Swagger 2.0 document contain duplicates.
- [path-parameters-defined](https://apigenie.pl/docs/linter/swagger/rules/path-parameters-defined.md): This rule checks whether every parameter of a path template is declared as a path parameter.
- [path-parameters-on-items](https://apigenie.pl/docs/linter/swagger/rules/path-parameters-on-items.md): This rule checks whether path parameters are declared on path items rather than on individual operations.
- [paths-max-count](https://apigenie.pl/docs/linter/swagger/rules/paths-max-count.md): This rule checks whether a Swagger 2.0 document defines more paths than a configured maximum.
- [paths-max-depth](https://apigenie.pl/docs/linter/swagger/rules/paths-max-depth.md): This rule checks whether the paths of a Swagger 2.0 document are nested deeper than a configured maximum.
- [paths-sorted](https://apigenie.pl/docs/linter/swagger/rules/paths-sorted.md): This rule checks whether the paths of a Swagger 2.0 document are sorted.
- [paths-unique](https://apigenie.pl/docs/linter/swagger/rules/paths-unique.md): This rule checks whether a Swagger 2.0 document defines paths that are equivalent to each other.
- [paths-well-formed](https://apigenie.pl/docs/linter/swagger/rules/paths-well-formed.md): This rule checks whether the paths of a Swagger 2.0 document are well-formed.
- [safe-markdown](https://apigenie.pl/docs/linter/swagger/rules/safe-markdown.md): This rule ensures that the GFM descriptions of a Swagger 2.0 document do not contain unsafe constructs like `script` elements or `eval()` calls.
- [schema-constraints](https://apigenie.pl/docs/linter/swagger/rules/schema-constraints.md): This rule ensures that typed objects of a Swagger 2.0 document define constraints restricting the size of the underlying data.
- [schema-datetime-suffix](https://apigenie.pl/docs/linter/swagger/rules/schema-datetime-suffix.md): This rule ensures that the names of date and date-time properties end with a common suffix.
- [schema-enum-naming](https://apigenie.pl/docs/linter/swagger/rules/schema-enum-naming.md): This rule ensures that the string values of `enum` lists adhere to a predefined naming convention.
- [schema-enum-no-duplicates](https://apigenie.pl/docs/linter/swagger/rules/schema-enum-no-duplicates.md): This rule ensures that `enum` lists do not contain duplicate values.
- [schema-enum-types](https://apigenie.pl/docs/linter/swagger/rules/schema-enum-types.md): This rule ensures that all values of an `enum` list match the declared `type`.
- [schema-example-defined](https://apigenie.pl/docs/linter/swagger/rules/schema-example-defined.md): This rule ensures that the schemas of a Swagger 2.0 document provide examples.
- [schema-format-defined](https://apigenie.pl/docs/linter/swagger/rules/schema-format-defined.md): This rule ensures that numeric objects declare the size of their values with a `format`.
- [schema-format-deprecated](https://apigenie.pl/docs/linter/swagger/rules/schema-format-deprecated.md): This rule reports the formats which the OpenAPI format registry marks as deprecated from OpenAPI 3.1, and names what replaces them.
- [schema-format-type-mismatch](https://apigenie.pl/docs/linter/swagger/rules/schema-format-type-mismatch.md): This rule ensures that the `format` of an object is one that applies to its `type`.
- [schema-format-unknown](https://apigenie.pl/docs/linter/swagger/rules/schema-format-unknown.md): This rule reports a `format` of a Swagger 2.0 document which is neither in the OpenAPI format registry nor declared in `openapi.custom_formats` of the configuration file.
- [schema-no-additional-properties](https://apigenie.pl/docs/linter/swagger/rules/schema-no-additional-properties.md): This rule ensures that object schemas do not accept arbitrary additional properties.
- [schema-property-naming](https://apigenie.pl/docs/linter/swagger/rules/schema-property-naming.md): This rule ensures that the names of schema properties adhere to a predefined naming convention.
- [schema-required-properties-defined](https://apigenie.pl/docs/linter/swagger/rules/schema-required-properties-defined.md): This rule checks that every name listed in `required` is declared in `properties`.
- [schemes-secure](https://apigenie.pl/docs/linter/swagger/rules/schemes-secure.md): This rule checks whether a Swagger 2.0 document serves its API over secure transfer protocols only, and whether its host is written in lower case.
- [spell-check](https://apigenie.pl/docs/linter/swagger/rules/spell-check.md): This rule checks the spelling of the texts of a Swagger 2.0 document written for humans: titles, summaries and descriptions.
- [standard-media-types](https://apigenie.pl/docs/linter/swagger/rules/standard-media-types.md): This rule checks whether a Swagger 2.0 document uses only well-known media types.
- [swagger-validation](https://apigenie.pl/docs/linter/swagger/rules/swagger-validation.md): This rule reports violations of the Swagger 2.0 specification that span several objects, and therefore cannot be detected while a single object is read.
- [tag-description-defined](https://apigenie.pl/docs/linter/swagger/rules/tag-description-defined.md): This rule checks whether each tag declared in the root `tags` array of a Swagger 2.0 document has a meaningful description.
- [tags-sorted](https://apigenie.pl/docs/linter/swagger/rules/tags-sorted.md): This rule checks whether the tags in the root `tags` array of a Swagger 2.0 document are sorted by name.
- [tags-unique](https://apigenie.pl/docs/linter/swagger/rules/tags-unique.md): This rule checks whether the tags in the root `tags` array of a Swagger 2.0 document have unique names, comparing names case-insensitively.
- [unused-request-body](https://apigenie.pl/docs/linter/swagger/rules/unused-request-body.md): This rule checks whether `GET` and `HEAD` operations of a Swagger 2.0 document declare a request body.
- [unused-shared-component](https://apigenie.pl/docs/linter/swagger/rules/unused-shared-component.md): This rule checks whether every shared object of a Swagger 2.0 document is actually used.

## GraphQL linter rules

- [argument-description-defined](https://apigenie.pl/docs/linter/graphql/rules/argument-description-defined.md): This rule checks that the arguments of fields and directives have a description.
- [argument-naming](https://apigenie.pl/docs/linter/graphql/rules/argument-naming.md): This rule checks that the argument names follow a naming convention, camelCase by default.
- [arguments-sorted](https://apigenie.pl/docs/linter/graphql/rules/arguments-sorted.md): This rule checks that the arguments of field and directive definitions are in alphabetical order.
- [custom-scalar-specified-by](https://apigenie.pl/docs/linter/graphql/rules/custom-scalar-specified-by.md): This rule checks that custom scalars link their specification with `@specifiedBy`.
- [deprecation-date-defined](https://apigenie.pl/docs/linter/graphql/rules/deprecation-date-defined.md): This rule checks that `@deprecated` directives have a deletion date that has not passed.
- [deprecation-reason-defined](https://apigenie.pl/docs/linter/graphql/rules/deprecation-reason-defined.md): This rule checks that `@deprecated` directives have a reason.
- [description-capitalized](https://apigenie.pl/docs/linter/graphql/rules/description-capitalized.md): This rule checks that descriptions start with a capital letter.
- [description-style](https://apigenie.pl/docs/linter/graphql/rules/description-style.md): This rule checks that descriptions are written as block strings, or as single-line strings.
- [directive-description-defined](https://apigenie.pl/docs/linter/graphql/rules/directive-description-defined.md): This rule checks that directive definitions have a description.
- [directive-naming](https://apigenie.pl/docs/linter/graphql/rules/directive-naming.md): This rule checks that directive names follow a naming convention, camelCase by default.
- [enum-value-description-defined](https://apigenie.pl/docs/linter/graphql/rules/enum-value-description-defined.md): This rule checks that enum values have a description.
- [enum-value-naming](https://apigenie.pl/docs/linter/graphql/rules/enum-value-naming.md): This rule checks that enum value names follow a naming convention, CONST_CASE by default.
- [enum-values-sorted](https://apigenie.pl/docs/linter/graphql/rules/enum-values-sorted.md): This rule checks that the values of each enum type definition and extension are in alphabetical order.
- [field-description-defined](https://apigenie.pl/docs/linter/graphql/rules/field-description-defined.md): This rule checks that the fields of object and interface types have a description.
- [field-naming](https://apigenie.pl/docs/linter/graphql/rules/field-naming.md): This rule checks that the field names follow a naming convention, camelCase by default.
- [fields-on-correct-type](https://apigenie.pl/docs/linter/graphql/rules/fields-on-correct-type.md): This rule checks that the fields selected by operations are defined by their parent types.
- [fields-sorted](https://apigenie.pl/docs/linter/graphql/rules/fields-sorted.md): This rule checks that the fields of each object and interface type definition and extension are in alphabetical order.
- [fragment-naming](https://apigenie.pl/docs/linter/graphql/rules/fragment-naming.md): This rule checks that fragment names follow a naming convention, PascalCase by default.
- [input-field-description-defined](https://apigenie.pl/docs/linter/graphql/rules/input-field-description-defined.md): This rule checks that the fields of input object types have a description.
- [input-field-naming](https://apigenie.pl/docs/linter/graphql/rules/input-field-naming.md): This rule checks that the input field names follow a naming convention, camelCase by default.
- [input-fields-sorted](https://apigenie.pl/docs/linter/graphql/rules/input-fields-sorted.md): This rule checks that the fields of each input object type definition and extension are in alphabetical order.
- [input-no-circular-non-null](https://apigenie.pl/docs/linter/graphql/rules/input-no-circular-non-null.md): This rule checks that input object types don't reference themselves through non-null fields.
- [input-output-types](https://apigenie.pl/docs/linter/graphql/rules/input-output-types.md): This rule checks that arguments and input fields have input types, and fields have output types, as the GraphQL specification requires.
- [input-type-suffix](https://apigenie.pl/docs/linter/graphql/rules/input-type-suffix.md): This rule checks that input object type names end with a suffix, `Input` by default.
- [interface-implementation](https://apigenie.pl/docs/linter/graphql/rules/interface-implementation.md): This rule checks that object and interface types implement their interfaces with all their fields, compatible field types and matching arguments, as the GraphQL specification requires.
- [known-argument-names](https://apigenie.pl/docs/linter/graphql/rules/known-argument-names.md): This rule checks that the arguments given to fields and directives are defined by them.
- [known-directive-locations](https://apigenie.pl/docs/linter/graphql/rules/known-directive-locations.md): This rule checks that directives are used at one of the locations of their definition, as the GraphQL specification requires.
- [known-fragment-names](https://apigenie.pl/docs/linter/graphql/rules/known-fragment-names.md): This rule checks that fragment spreads name fragments of the document, as the GraphQL specification requires.
- [known-types](https://apigenie.pl/docs/linter/graphql/rules/known-types.md): This rule checks that the types referenced by type system definitions are built-in scalars or defined in the document, as the GraphQL specification requires.
- [lone-anonymous-operation](https://apigenie.pl/docs/linter/graphql/rules/lone-anonymous-operation.md): This rule checks that an anonymous operation is the only operation of the document, as the GraphQL specification requires.
- [lone-executable-definition](https://apigenie.pl/docs/linter/graphql/rules/lone-executable-definition.md): This rule checks that a document holds a single operation or fragment.
- [lone-schema-definition](https://apigenie.pl/docs/linter/graphql/rules/lone-schema-definition.md): This rule checks that a document has at most one schema definition, as the GraphQL specification requires.
- [match-document-filename](https://apigenie.pl/docs/linter/graphql/rules/match-document-filename.md): This rule checks that the file name of a document with one operation or fragment is the name of the definition.
- [mutation-input-argument](https://apigenie.pl/docs/linter/graphql/rules/mutation-input-argument.md): This rule checks that mutation fields take a single argument, `input`, of a non-null input object type.
- [mutation-payload-suffix](https://apigenie.pl/docs/linter/graphql/rules/mutation-payload-suffix.md): This rule checks that the result types of mutation fields end with a suffix, `Payload` by default.
- [no-deprecated](https://apigenie.pl/docs/linter/graphql/rules/no-deprecated.md): This rule checks that operations don't use deprecated fields, arguments and enum values.
- [no-deprecated-required-argument](https://apigenie.pl/docs/linter/graphql/rules/no-deprecated-required-argument.md): This rule checks that required arguments and input fields are not deprecated.
- [no-fragment-cycles](https://apigenie.pl/docs/linter/graphql/rules/no-fragment-cycles.md): This rule checks that fragments don't spread themselves, directly or indirectly, as the GraphQL specification requires.
- [no-get-prefix-on-query-fields](https://apigenie.pl/docs/linter/graphql/rules/no-get-prefix-on-query-fields.md): This rule checks that the fields of the query root type are not named `getSomething`.
- [no-hashtag-description](https://apigenie.pl/docs/linter/graphql/rules/no-hashtag-description.md): This rule checks that definitions are documented with descriptions rather than with `#` comments.
- [no-mixed-definitions](https://apigenie.pl/docs/linter/graphql/rules/no-mixed-definitions.md): This rule checks that a document holds either a schema or operations, not both.
- [no-one-place-fragments](https://apigenie.pl/docs/linter/graphql/rules/no-one-place-fragments.md): This rule checks that fragments are spread more than once in the document.
- [no-root-type](https://apigenie.pl/docs/linter/graphql/rules/no-root-type.md): This rule checks that the schema doesn't have the root operation types the configuration disallows.
- [no-scalar-result-on-mutation](https://apigenie.pl/docs/linter/graphql/rules/no-scalar-result-on-mutation.md): This rule checks that mutation fields return object types rather than scalars.
- [no-type-suffix](https://apigenie.pl/docs/linter/graphql/rules/no-type-suffix.md): This rule checks that type names don't end with a redundant suffix such as `Type` or `Enum`.
- [no-typename-prefix](https://apigenie.pl/docs/linter/graphql/rules/no-typename-prefix.md): This rule checks that field names don't start with the name of their type, as in `User.userId`.
- [no-undefined-variables](https://apigenie.pl/docs/linter/graphql/rules/no-undefined-variables.md): This rule checks that the variables used by an operation, including in the fragments it spreads, are defined by the operation, as the GraphQL specification requires.
- [no-unused-fragments](https://apigenie.pl/docs/linter/graphql/rules/no-unused-fragments.md): This rule checks that every fragment is spread by an operation, directly or through other fragments, as the GraphQL specification requires.
- [no-unused-variables](https://apigenie.pl/docs/linter/graphql/rules/no-unused-variables.md): This rule checks that the variables defined by an operation are used, as the GraphQL specification requires.
- [one-field-subscriptions](https://apigenie.pl/docs/linter/graphql/rules/one-field-subscriptions.md): This rule checks that subscriptions select a single root field, as the specification requires.
- [oneof-fields-nullable](https://apigenie.pl/docs/linter/graphql/rules/oneof-fields-nullable.md): This rule checks that the fields of `@oneOf` input object types are nullable and have no default value.
- [operation-known-types](https://apigenie.pl/docs/linter/graphql/rules/operation-known-types.md): This rule checks that the types of variables and the type conditions of fragments are types of the schema.
- [operation-name-defined](https://apigenie.pl/docs/linter/graphql/rules/operation-name-defined.md): This rule checks that operations have names.
- [operation-name-suffix](https://apigenie.pl/docs/linter/graphql/rules/operation-name-suffix.md): This rule checks that operation and fragment names don't end with a redundant suffix.
- [operation-naming](https://apigenie.pl/docs/linter/graphql/rules/operation-naming.md): This rule checks that operation names follow a naming convention, PascalCase by default.
- [possible-type-extensions](https://apigenie.pl/docs/linter/graphql/rules/possible-type-extensions.md): This rule checks that extended types have the same kind as their definition, as the GraphQL specification requires.
- [query-root-defined](https://apigenie.pl/docs/linter/graphql/rules/query-root-defined.md): This rule checks that the schema has a query root operation type.
- [relay-arguments](https://apigenie.pl/docs/linter/graphql/rules/relay-arguments.md): This rule checks that fields returning connections take the pagination arguments of the Relay Cursor Connections specification.
- [relay-connection-types](https://apigenie.pl/docs/linter/graphql/rules/relay-connection-types.md): This rule checks that connection types follow the Relay Cursor Connections specification.
- [relay-edge-types](https://apigenie.pl/docs/linter/graphql/rules/relay-edge-types.md): This rule checks that the edge types of connections follow the Relay Cursor Connections specification.
- [relay-page-info](https://apigenie.pl/docs/linter/graphql/rules/relay-page-info.md): This rule checks that a schema with connections has a `PageInfo` type as the Relay Cursor Connections specification defines it.
- [require-selections](https://apigenie.pl/docs/linter/graphql/rules/require-selections.md): This rule checks that selections of objects with an identifier select it.
- [required-arguments-provided](https://apigenie.pl/docs/linter/graphql/rules/required-arguments-provided.md): This rule checks that the required arguments of fields and directives are given.
- [reserved-names](https://apigenie.pl/docs/linter/graphql/rules/reserved-names.md): This rule checks that the names of types, fields, arguments, enum values and directives don't start with "__", as the GraphQL specification requires.
- [root-fields-nullable](https://apigenie.pl/docs/linter/graphql/rules/root-fields-nullable.md): This rule checks that the fields of the query and mutation root types are nullable.
- [selection-set-depth](https://apigenie.pl/docs/linter/graphql/rules/selection-set-depth.md): This rule checks that selection sets are nested at most 7 levels deep.
- [selections-sorted](https://apigenie.pl/docs/linter/graphql/rules/selections-sorted.md): This rule checks that the fields of each selection set of operations and fragments are in alphabetical order.
- [spell-check](https://apigenie.pl/docs/linter/graphql/rules/spell-check.md): This rule checks the spelling of descriptions and comments.
- [strict-id-in-types](https://apigenie.pl/docs/linter/graphql/rules/strict-id-in-types.md): This rule checks that object types have exactly one non-null identifier field, `id: ID!` by default.
- [type-description-defined](https://apigenie.pl/docs/linter/graphql/rules/type-description-defined.md): This rule checks that type definitions have a description.
- [type-naming](https://apigenie.pl/docs/linter/graphql/rules/type-naming.md): This rule checks that type names follow a naming convention, PascalCase by default.
- [types-sorted](https://apigenie.pl/docs/linter/graphql/rules/types-sorted.md): This rule checks that the type definitions of a document, and its directive definitions are in alphabetical order.
- [unique-argument-definition-names](https://apigenie.pl/docs/linter/graphql/rules/unique-argument-definition-names.md): This rule checks that the argument names of a field or directive definition are unique, as the GraphQL specification requires.
- [unique-argument-names](https://apigenie.pl/docs/linter/graphql/rules/unique-argument-names.md): This rule checks that the argument names of a field or directive are unique, as the GraphQL specification requires.
- [unique-directive-names](https://apigenie.pl/docs/linter/graphql/rules/unique-directive-names.md): This rule checks that directive names are unique, as the GraphQL specification requires.
- [unique-directives-per-location](https://apigenie.pl/docs/linter/graphql/rules/unique-directives-per-location.md): This rule checks that non-repeatable directives are used once per location, as the GraphQL specification requires.
- [unique-enum-value-names](https://apigenie.pl/docs/linter/graphql/rules/unique-enum-value-names.md): This rule checks that the values of an enum are unique across the enum and its extensions, as the GraphQL specification requires.
- [unique-field-definition-names](https://apigenie.pl/docs/linter/graphql/rules/unique-field-definition-names.md): This rule checks that the field names of a type are unique across the type and its extensions, as the GraphQL specification requires.
- [unique-fragment-names](https://apigenie.pl/docs/linter/graphql/rules/unique-fragment-names.md): This rule checks that fragment names are unique, as the GraphQL specification requires.
- [unique-input-field-names](https://apigenie.pl/docs/linter/graphql/rules/unique-input-field-names.md): This rule checks that the field names of an object value are unique, as the GraphQL specification requires.
- [unique-operation-names](https://apigenie.pl/docs/linter/graphql/rules/unique-operation-names.md): This rule checks that operation names are unique, as the GraphQL specification requires.
- [unique-operation-types](https://apigenie.pl/docs/linter/graphql/rules/unique-operation-types.md): This rule checks that each root operation type is defined once across the schema definition and its extensions, as the GraphQL specification requires.
- [unique-type-names](https://apigenie.pl/docs/linter/graphql/rules/unique-type-names.md): This rule checks that type names are unique, as the GraphQL specification requires.
- [unique-variable-names](https://apigenie.pl/docs/linter/graphql/rules/unique-variable-names.md): This rule checks that the variable names of an operation are unique, as the GraphQL specification requires.
- [unreachable-types](https://apigenie.pl/docs/linter/graphql/rules/unreachable-types.md): This rule checks that every type is reachable from the root operation types.
- [unused-directive-definition](https://apigenie.pl/docs/linter/graphql/rules/unused-directive-definition.md): This rule checks that the directives defined for schemas are applied in the document.
- [variables-sorted](https://apigenie.pl/docs/linter/graphql/rules/variables-sorted.md): This rule checks that the variable definitions of each operation are in alphabetical order.

## Protobuf linter rules

- [directory-same-package](https://apigenie.pl/docs/linter/protobuf/rules/directory-same-package.md): This rule checks whether all the `.proto` files of a directory declare the same package.
- [enum-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/enum-comment-defined.md): This rule checks whether every enum of a Protobuf file has a leading comment.
- [enum-naming](https://apigenie.pl/docs/linter/protobuf/rules/enum-naming.md): This rule checks whether the name of every enum of a Protobuf file is in `PascalCase`.
- [enum-no-allow-alias](https://apigenie.pl/docs/linter/protobuf/rules/enum-no-allow-alias.md): This rule checks whether any enum sets the `allow_alias` option.
- [enum-value-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/enum-value-comment-defined.md): This rule checks whether every enum value of a Protobuf file has a leading comment.
- [enum-value-naming](https://apigenie.pl/docs/linter/protobuf/rules/enum-value-naming.md): This rule checks whether the name of every enum value of a Protobuf file is in `UPPER_SNAKE_CASE`.
- [enum-value-prefix](https://apigenie.pl/docs/linter/protobuf/rules/enum-value-prefix.md): This rule checks whether the names of the values of every enum start with the name of the enum in `UPPER_SNAKE_CASE`, for example `PET_KIND_DOG` in the enum `PetKind`.
- [enum-zero-value-suffix](https://apigenie.pl/docs/linter/protobuf/rules/enum-zero-value-suffix.md): This rule checks whether the zero value of every enum ends with a suffix, `_UNSPECIFIED` by default.
- [field-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/field-comment-defined.md): This rule checks whether every field of a Protobuf file has a leading comment.
- [field-naming](https://apigenie.pl/docs/linter/protobuf/rules/field-naming.md): This rule checks whether the name of every field of a Protobuf file is in `lower_snake_case`.
- [file-naming](https://apigenie.pl/docs/linter/protobuf/rules/file-naming.md): This rule checks whether the name of every Protobuf file is in `lower_snake_case`, with the `.proto` extension.
- [import-no-cycle](https://apigenie.pl/docs/linter/protobuf/rules/import-no-cycle.md): This rule checks whether Protobuf files import each other in a cycle.
- [import-no-public](https://apigenie.pl/docs/linter/protobuf/rules/import-no-public.md): This rule checks whether a Protobuf file uses `import public`.
- [import-no-weak](https://apigenie.pl/docs/linter/protobuf/rules/import-no-weak.md): This rule checks whether a Protobuf file uses `import weak`.
- [import-resolved](https://apigenie.pl/docs/linter/protobuf/rules/import-resolved.md): This rule checks whether every file imported by a Protobuf file can be found.
- [import-used](https://apigenie.pl/docs/linter/protobuf/rules/import-used.md): This rule checks whether every file imported by a Protobuf file is actually used.
- [imports-sorted](https://apigenie.pl/docs/linter/protobuf/rules/imports-sorted.md): This rule checks whether the import statements of a Protobuf file are sorted by path.
- [message-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/message-comment-defined.md): This rule checks whether every message of a Protobuf file has a leading comment.
- [message-naming](https://apigenie.pl/docs/linter/protobuf/rules/message-naming.md): This rule checks whether the name of every message of a Protobuf file is in `PascalCase`.
- [oneof-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/oneof-comment-defined.md): This rule checks whether every oneof of a Protobuf file has a leading comment.
- [oneof-naming](https://apigenie.pl/docs/linter/protobuf/rules/oneof-naming.md): This rule checks whether the name of every oneof of a Protobuf file is in `lower_snake_case`.
- [package-defined](https://apigenie.pl/docs/linter/protobuf/rules/package-defined.md): This rule checks whether every Protobuf file declares a package.
- [package-directory-match](https://apigenie.pl/docs/linter/protobuf/rules/package-directory-match.md): This rule checks whether every Protobuf file is in the directory that corresponds to its package, for example `acme/pets/v1` for the package `acme.pets.v1`.
- [package-naming](https://apigenie.pl/docs/linter/protobuf/rules/package-naming.md): This rule checks whether the package name of a Protobuf file consists of `lower_snake_case` components separated by dots.
- [package-no-import-cycle](https://apigenie.pl/docs/linter/protobuf/rules/package-no-import-cycle.md): This rule checks whether packages import each other in a cycle.
- [package-options-consistent](https://apigenie.pl/docs/linter/protobuf/rules/package-options-consistent.md): This rule checks whether the files of a package set the same language-specific file options, such as `go_package` and `java_package`.
- [package-same-directory](https://apigenie.pl/docs/linter/protobuf/rules/package-same-directory.md): This rule checks whether all the files of a package are in the same directory.
- [package-version-suffix](https://apigenie.pl/docs/linter/protobuf/rules/package-version-suffix.md): This rule checks whether the last component of the package name of a Protobuf file is a version, such as `v1` or `v1beta2`.
- [rpc-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/rpc-comment-defined.md): This rule checks whether every RPC of a Protobuf file has a leading comment.
- [rpc-naming](https://apigenie.pl/docs/linter/protobuf/rules/rpc-naming.md): This rule checks whether the name of every RPC of a Protobuf file is in `PascalCase`.
- [rpc-no-client-streaming](https://apigenie.pl/docs/linter/protobuf/rules/rpc-no-client-streaming.md): This rule checks whether any RPC uses client streaming.
- [rpc-no-server-streaming](https://apigenie.pl/docs/linter/protobuf/rules/rpc-no-server-streaming.md): This rule checks whether any RPC uses server streaming.
- [rpc-request-response-unique](https://apigenie.pl/docs/linter/protobuf/rules/rpc-request-response-unique.md): This rule checks whether every message is used as the request or the response of a single RPC.
- [rpc-request-standard-name](https://apigenie.pl/docs/linter/protobuf/rules/rpc-request-standard-name.md): This rule checks whether the request type of every RPC is named after the RPC, for example `GetPetRequest` for the RPC `GetPet`.
- [rpc-response-standard-name](https://apigenie.pl/docs/linter/protobuf/rules/rpc-response-standard-name.md): This rule checks whether the response type of every RPC is named after the RPC, for example `GetPetResponse` for the RPC `GetPet`.
- [service-comment-defined](https://apigenie.pl/docs/linter/protobuf/rules/service-comment-defined.md): This rule checks whether every service of a Protobuf file has a leading comment.
- [service-naming](https://apigenie.pl/docs/linter/protobuf/rules/service-naming.md): This rule checks whether the name of every service of a Protobuf file is in `PascalCase`.
- [service-suffix](https://apigenie.pl/docs/linter/protobuf/rules/service-suffix.md): This rule checks whether the name of every service ends with a suffix, `Service` by default.
- [spell-check](https://apigenie.pl/docs/linter/protobuf/rules/spell-check.md): This rule checks the spelling of the comments of a Protobuf file.

## Optional

- [One mock server for every contract: meet apigenie-server](https://apigenie.pl/blog/mocking-any-api-with-apigenie-server.md): apigenie-server serves OpenAPI, Swagger, AsyncAPI, gRPC and GraphQL contracts as working mock APIs, and in front of a real server it becomes a validating proxy that turns your traffic into a contract test.
- [Catching breaking changes with apigenie diff](https://apigenie.pl/blog/catching-breaking-changes-with-apigenie-diff.md): How API Genie compares two versions of an OpenAPI, Swagger, AsyncAPI, Protobuf or GraphQL description, rates every change, and stops a pull request that would break your clients.
- [How to keep your OpenAPI schemas in good shape](https://apigenie.pl/blog/formatter-is-a-good-start.md)
- [Rethinking RESTful API Development: From Schema-First to API Genie](https://apigenie.pl/blog/from-schema-first-to-apigenie.md): Schema-first approach for developing RESTful APIs, despite numerous advantages, has not become mainstream. Let's see why.
- [We need better REST](https://apigenie.pl/blog/we-need-better-rest-en.md): I believe that the REST-based approach needs to be modernized. That's why I created the API Genie project.
- [Potrzebujemy lepszego RESTa](https://apigenie.pl/blog/we-need-better-rest-pl.md): Uważam, że podejście oparte o REST wymaga unowocześnienia. Po to stworzyłem projekt API Genie.