boolean-parameter-prefixes

May 18, 2026 · View on GitHub

Enforces specific and consistent naming for request parameters with boolean type. When this rule is enabled, the name fields of all boolean parameters in your API must contain one of the configured prefixes.

OASCompatibility
2.0✅
3.0✅
3.1✅
3.2✅
flowchart TD

Root ==> Paths --> PathItem --> Operation --> Parameter --enforces names for boolean types--> Schema
PathItem --> Parameter
NamedParameters --> Parameter

Root ==> components

subgraph components
NamedParameters
end

style Parameter fill:#codaf9,stroke:#0044d4,stroke-width:5px
style Schema fill:#codaf9,stroke:#0044d4,stroke-width:5px

API design principles

Consistency in API design makes APIs easier to use. Being able to identity boolean types from their names is possible when they use consistent prefixes, such as is or has. If you saw an API with these parameters, you could identify the boolean parameters by their names:

  • orderNumber
  • amount
  • hasPaid
  • shippingService
  • isFulfilled
  • customerReference

The nuance of being able to identify the boolean parameters helps developers produce and consume APIs.

Configuration

OptionTypeDescription
severitystringPossible values: off, warn, error. Default off.
prefixes[string]List of allowed boolean parameter prefixes. Default values are is and has.

An example configuration:

rules:
  boolean-parameter-prefixes: error

The following example configures prefixes:

rules:
  boolean-parameter-prefixes:
    severity: error
    prefixes: [can, is, has]

Examples

Given the configuration with the prefixes can, is, and has, the following example shows an error.

Example of incorrect boolean parameter prefixes:

schema:
  type: object
  properties:
    belongsToUser:
      type: boolean
      default: false

Example of correct boolean parameter prefixes:

schema:
  type: object
  properties:
    isUser:
      type: boolean
      default: false

Resources