---
title: "Create a OasValidation plugin"
method: POST
path: "/{workspace}/plugins#OasValidation"
tags: ["Plugins"]
---

# Create a OasValidation plugin

`POST /{workspace}/plugins#OasValidation`

Create a OasValidation plugin

## Request body

- OasValidationPlugin — A Plugin entity represents a plugin configuration that will be executed during the HTTP request/response lifecycle. It is how you can add functionalities to Services that run behind Kong, like Authentication or Rate Limiting for example. You can find more information about how to install and what values each plugin takes by visiting the [Kong Hub](https://docs.konghq.com/hub/). When adding a Plugin Configuration to a Service, every request made by a client to that Service will run said Plugin. If a Plugin needs to be tuned to different values for some specific Consumers, you can do so by creating a separate plugin instance that specifies both the Service and the Consumer, through the `service` and `consumer` fields.
  - `condition` string, nullable — An expression used for conditional control over plugin execution. If the expression evaluates to `true` during the request flow, the plugin is executed; otherwise, it is skipped.
  - `created_at` integer, nullable — Unix epoch when the resource was created.
  - `enabled` boolean, nullable — Whether the plugin is applied.
  - `id` string, nullable — A string representing a UUID (universally unique identifier).
  - `instance_name` string, nullable — A unique string representing a UTF-8 encoded name.
  - `name` 'oas-validation', required — The name of the Plugin that's going to be added. Currently, the Plugin must be installed in every Kong instance separately.
  - `ordering` object, nullable
    - `after` object
      - `access` string[]
    - `before` object
      - `access` string[]
  - `partials` object[] — A list of partials to be used by the plugin.
    - `id` string — A string representing a UUID (universally unique identifier).
    - `name` string — A unique string representing a UTF-8 encoded name.
    - `path` string
  - `tags` string[], nullable — An optional set of strings associated with the Plugin for grouping and filtering.
  - `updated_at` integer, nullable — Unix epoch when the resource was last updated.
  - `config` object, required
    - `allowed_header_parameters` string — List of header parameters in the request that will be ignored when performing HTTP header validation. These are additional headers added to an API request beyond those defined in the API specification. For example, you might include the HTTP header `User-Agent`, which lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent.
    - `api_spec` string, required — The API specification defined using either Swagger or the OpenAPI. This can be either a JSON or YAML based file. If using a YAML file, the spec needs to be URI-Encoded to preserve the YAML format.
    - `api_spec_encoded` boolean — Indicates whether the api_spec is URI-Encoded.
    - `collect_all_errors` boolean — If set to true, collects all schema validation errors instead of stopping at the first. Applies only to JSON Schema validation (parameter values, request/response body); pre-validation checks such as path-not-found, unsupported content-type, and unknown parameters are fail-fast and always stop at the first error regardless of this setting. Only takes effect when `structured_errors` is set to `false`. Note: Enabling this option will affect performance.
    - `custom_base_path` string — The base path to be used for path match evaluation. This value is ignored if `include_base_path` is set to `false`.
    - `header_parameter_check` boolean — If set to true, checks if HTTP header parameters in the request exist in the API specification.
    - `include_base_path` boolean — Indicates whether to include the base path when performing path match evaluation.
    - `max_structured_errors` integer — When set, caps the number of structured errors returned in the `errors` array to the specified value (must be greater than 0). Applies only to JSON Schema validation errors; pre-validation failures such as path-not-found, unsupported content-type, and unknown parameters always produce a single error entry. When not set, no cap is applied. Requires `structured_errors` to be enabled.
    - `notify_only_request_validation_failure` boolean — If set to true, notifications via event hooks are enabled, but request based validation failures don't affect the request flow.
    - `notify_only_response_body_validation_failure` boolean — If set to true, notifications via event hooks are enabled, but response validation failures don't affect the response flow.
    - `query_parameter_check` boolean — If set to true, checks if query parameters in the request exist in the API specification.
    - `structured_errors` boolean — If set to true, schema validation failures are returned as a structured `errors` array, where each entry contains `instanceLocation`, `keywordLocation`, and `error`. Pre-validation failures such as path-not-found or unsupported content-type also return an `errors` array, but entries contain only an `error` field. Requires `verbose_response` to be enabled. Use `max_structured_errors` to cap the response size.
    - `validate_request_body` boolean — If set to true, validates the request body content against the API specification.
    - `validate_request_header_params` boolean — If set to true, validates HTTP header parameters against the API specification.
    - `validate_request_query_params` boolean — If set to true, validates query parameters against the API specification.
    - `validate_request_uri_params` boolean — If set to true, validates URI parameters in the request against the API specification.
    - `validate_response_body` boolean — If set to true, validates the response from the upstream services against the API specification. If validation fails, it results in an `HTTP 406 Not Acceptable` status code.
    - `verbose_response` boolean — If set to true, returns a detailed error message for invalid requests & responses. This is useful while testing.
  - `consumer` object — If set, the plugin will activate only for requests where the specified has been authenticated. (Note that some plugins can not be restricted to consumers this way.). Leave unset for the plugin to activate regardless of the authenticated Consumer.
    - `id` string
  - `protocols` string[] — A set of strings representing HTTP protocols.
  - `route` object — If set, the plugin will only activate when receiving requests via the specified route. Leave unset for the plugin to activate regardless of the route being used.
    - `id` string
  - `service` object — If set, the plugin will only activate when receiving requests via one of the routes belonging to the specified Service. Leave unset for the plugin to activate regardless of the Service being matched.
    - `id` string

## Response `201`

Created OasValidation plugin

- OasValidationPlugin — A Plugin entity represents a plugin configuration that will be executed during the HTTP request/response lifecycle. It is how you can add functionalities to Services that run behind Kong, like Authentication or Rate Limiting for example. You can find more information about how to install and what values each plugin takes by visiting the [Kong Hub](https://docs.konghq.com/hub/). When adding a Plugin Configuration to a Service, every request made by a client to that Service will run said Plugin. If a Plugin needs to be tuned to different values for some specific Consumers, you can do so by creating a separate plugin instance that specifies both the Service and the Consumer, through the `service` and `consumer` fields.
  - `condition` string, nullable — An expression used for conditional control over plugin execution. If the expression evaluates to `true` during the request flow, the plugin is executed; otherwise, it is skipped.
  - `created_at` integer, nullable — Unix epoch when the resource was created.
  - `enabled` boolean, nullable — Whether the plugin is applied.
  - `id` string, nullable — A string representing a UUID (universally unique identifier).
  - `instance_name` string, nullable — A unique string representing a UTF-8 encoded name.
  - `name` 'oas-validation', required — The name of the Plugin that's going to be added. Currently, the Plugin must be installed in every Kong instance separately.
  - `ordering` object, nullable
    - `after` object
      - `access` string[]
    - `before` object
      - `access` string[]
  - `partials` object[] — A list of partials to be used by the plugin.
    - `id` string — A string representing a UUID (universally unique identifier).
    - `name` string — A unique string representing a UTF-8 encoded name.
    - `path` string
  - `tags` string[], nullable — An optional set of strings associated with the Plugin for grouping and filtering.
  - `updated_at` integer, nullable — Unix epoch when the resource was last updated.
  - `config` object, required
    - `allowed_header_parameters` string — List of header parameters in the request that will be ignored when performing HTTP header validation. These are additional headers added to an API request beyond those defined in the API specification. For example, you might include the HTTP header `User-Agent`, which lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent.
    - `api_spec` string, required — The API specification defined using either Swagger or the OpenAPI. This can be either a JSON or YAML based file. If using a YAML file, the spec needs to be URI-Encoded to preserve the YAML format.
    - `api_spec_encoded` boolean — Indicates whether the api_spec is URI-Encoded.
    - `collect_all_errors` boolean — If set to true, collects all schema validation errors instead of stopping at the first. Applies only to JSON Schema validation (parameter values, request/response body); pre-validation checks such as path-not-found, unsupported content-type, and unknown parameters are fail-fast and always stop at the first error regardless of this setting. Only takes effect when `structured_errors` is set to `false`. Note: Enabling this option will affect performance.
    - `custom_base_path` string — The base path to be used for path match evaluation. This value is ignored if `include_base_path` is set to `false`.
    - `header_parameter_check` boolean — If set to true, checks if HTTP header parameters in the request exist in the API specification.
    - `include_base_path` boolean — Indicates whether to include the base path when performing path match evaluation.
    - `max_structured_errors` integer — When set, caps the number of structured errors returned in the `errors` array to the specified value (must be greater than 0). Applies only to JSON Schema validation errors; pre-validation failures such as path-not-found, unsupported content-type, and unknown parameters always produce a single error entry. When not set, no cap is applied. Requires `structured_errors` to be enabled.
    - `notify_only_request_validation_failure` boolean — If set to true, notifications via event hooks are enabled, but request based validation failures don't affect the request flow.
    - `notify_only_response_body_validation_failure` boolean — If set to true, notifications via event hooks are enabled, but response validation failures don't affect the response flow.
    - `query_parameter_check` boolean — If set to true, checks if query parameters in the request exist in the API specification.
    - `structured_errors` boolean — If set to true, schema validation failures are returned as a structured `errors` array, where each entry contains `instanceLocation`, `keywordLocation`, and `error`. Pre-validation failures such as path-not-found or unsupported content-type also return an `errors` array, but entries contain only an `error` field. Requires `verbose_response` to be enabled. Use `max_structured_errors` to cap the response size.
    - `validate_request_body` boolean — If set to true, validates the request body content against the API specification.
    - `validate_request_header_params` boolean — If set to true, validates HTTP header parameters against the API specification.
    - `validate_request_query_params` boolean — If set to true, validates query parameters against the API specification.
    - `validate_request_uri_params` boolean — If set to true, validates URI parameters in the request against the API specification.
    - `validate_response_body` boolean — If set to true, validates the response from the upstream services against the API specification. If validation fails, it results in an `HTTP 406 Not Acceptable` status code.
    - `verbose_response` boolean — If set to true, returns a detailed error message for invalid requests & responses. This is useful while testing.
  - `consumer` object — If set, the plugin will activate only for requests where the specified has been authenticated. (Note that some plugins can not be restricted to consumers this way.). Leave unset for the plugin to activate regardless of the authenticated Consumer.
    - `id` string
  - `protocols` string[] — A set of strings representing HTTP protocols.
  - `route` object — If set, the plugin will only activate when receiving requests via the specified route. Leave unset for the plugin to activate regardless of the route being used.
    - `id` string
  - `service` object — If set, the plugin will only activate when receiving requests via one of the routes belonging to the specified Service. Leave unset for the plugin to activate regardless of the Service being matched.
    - `id` string

## Other responses

- `401` — Unauthorized

---

[API](https://skmtc.net/kong/apis/kong-enterprise-admin-api.md) · [All operations](https://skmtc.net/kong/apis/kong-enterprise-admin-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/kong/kong-enterprise-admin-api/revisions/28b1f8a59cdc/schema)