Speakeasy Logo
Skip to Content
OpenAPI HubRequestsRequest Parameters in OpenAPI best practices

Parameters in OpenAPI

Parameters are used to describe inputs to an operation. Parameters can be defined at the path or operation level and are merged with any duplicates at the operation level, overriding any defined at the path level.

Each parameter needs to be uniquely identified by a combination of its name and in fields in an operation.

A parameter in the list can either be a Parameter Object or a Reference to a Parameter Object defined in the Components Object under the parameters field.

Parameters can represent a number of different input types, including:

  • Path Parameters
  • Query Parameters
  • Headers
  • Cookies

Example:

paths:
  /drinks/{type}:
    parameters:
      - name: type
        in: path
        description: The type of drink to filter by.
        required: true
        schema:
          $ref: "#/components/schemas/DrinkType"
      - name: Cache-Control
        in: header
        description: The cache control header.
        required: false
        schema:
          type: string
          enum:
            - no-cache
            - no-store
            - must-revalidate
            - max-age=0
            - max-age=3600
            - max-age=86400
            - max-age=604800
            - max-age=2592000
            - max-age=31536000
    get:
      operationId: listDrinks
      summary: Get a list of drinks.
      description: Get a list of drinks, if authenticated this will include stock levels and product codes otherwise it will only include public information.
      security:
        - {}
      tags:
        - drinks
      parameters:
        - name: limit
          in: query
          description: The maximum number of drinks to return.
          required: false
          schema:
            type: integer
            minimum: 1
            maximum: 100
        - name: filter
          in: query
          description: Advanced filter criteria as a JSON object.
          required: false
          content:
            application/json:
              schema:
                type: object
                properties:
                  productCode:
                    type: string
                  inStock:
                    type: boolean
      responses:
        "200":
          description: A list of drinks.
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Drink"

Parameter Object

Parameter Object Fields

Field
Type
String
Required
✅
Description
The case sensitive name of the parameter. This must be unique when combined with the
field. If the
field is
, then this field must be referenced in the owning path.
Type
String
Required
✅
Description
The type or location of the parameter. The available types are:
  • - A templated parameter defined within the path.
  • - A query parameter passed via the URL.
  • - A header parameter passed via HTTP headers.
  • - A cookie parameter passed via HTTP cookies.
Type
String
Required
Description
A description of the parameter. This may contain CommonMark syntax  to provide a rich description.
Type
Boolean
Required
Description
Whether the parameter is required. If the
field is
, then this field is always required and must be
. Defaults to
.
Type
Boolean
Required
Description
Whether the parameter is deprecated. Defaults to
.
Type
String
Required
Description
Describes how the parameter value will be serialized depending on the
field. The available styles are
,
,
,
,
,
, and
. The default style depends on the
field:
  • -
  • -
  • -
  • -
See the path , header , query , and cookie  parameter sections for more details.
Type
Boolean
Required
Description
Whether the parameter value will be exploded, based on the parameter type. Defaults to
when
is
, otherwise
. See the path , header , query , and cookie  parameter sections for more details.
Required
Description
A schema or reference to a schema that defines the type of the parameter. This is required unless
is defined. Note: OpenAPI 3.0.x supports OpenAPI Reference Objects here as the value. OpenAPI 3.1.x uses the JSON Schema Referencing format.
Required
Description
A map of Media Type Objects that defines the possible media types that can be used for the parameter. This is required unless
is defined.
Type
Boolean
Required
Description
Whether the parameter value can be empty. Only used if
is
. Defaults to
.
Type
Boolean
Required
Description
Whether the parameter value can contain reserved characters as defined by RFC 3986 . Only used if
is
. Defaults to
.
Type
Any
Required
Description
An example of the parameter's value. This is ignored if the
field is defined.
Required
Description
A map of Example Objects and/or OpenAPI Reference Objects that define the possible examples of the parameter's value.
Required
Description
Any number of extension fields can be added to the parameter object that can be used by tooling and vendors.

The order of fields above is recommended for defining fields in the document.

Parameter Serialization

OpenAPI provides two mutually exclusive ways to describe how parameter values are serialized: using schema with style and explode, or using content. You must use one or the other, but not both.

The schema approach is the standard way to define parameters and is suitable for most scenarios. It works well for primitive values, arrays, and simple objects that can be serialized into a string.

With this approach, serialization is controlled by:

  • style: Defines the serialization format (e.g., form, simple, matrix, label)
  • explode: Controls whether arrays and objects are expanded into separate parameters

Example of array serialization using schema:

parameters:
  - name: colors
    in: query
    schema:
      type: array
      items:
        type: string
    style: form
    explode: false

This serializes as: ?colors=blue,black,brown

For detailed serialization rules for each parameter type, see the path, header, query, and cookie parameter documentation.

Content (For Complex Serialization)

The content approach is designed for complex serialization scenarios that cannot be handled by style and explode. This is particularly useful when you need to send structured data using a specific media type serialization, such as JSON.

Use content when you need to:

  • Send complex nested objects that require JSON serialization
  • Use a specific media type format for the parameter value
  • Handle serialization that goes beyond what style and explode support

Example of JSON-serialized object in a query parameter:

parameters:
  - name: filter
    in: query
    description: Filter criteria as a JSON object
    required: false
    content:
      application/json:
        schema:
          type: object
          properties:
            type:
              type: string
              example: t-shirt
            color:
              type: string
              example: blue
            priceRange:
              type: object
              properties:
                min:
                  type: number
                max:
                  type: number

This parameter would be sent as a JSON string in the URL:

?filter={"type":"t-shirt","color":"blue","priceRange":{"min":10,"max":50}}

The content field maps media types to schemas, allowing you to specify exactly how the parameter should be serialized and deserialized. While application/json is common for complex query parameters, you can use any media type that makes sense for your API.

Important: You cannot use style and explode when using content. Choose the approach that best fits your serialization needs.

Last updated on