---
title: "Update a OasValidation plugin"
method: PUT
path: "/plugins/{PluginId}#OasValidation"
tags: ["Plugins"]
---

# Update a OasValidation plugin

`PUT /plugins/{PluginId}#OasValidation`

Update 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.
  - `created_at` integer, nullable — Unix epoch when the resource was created.
  - `enabled` boolean, nullable — Whether the plugin is applied.
  - `id` string, nullable
  - `instance_name` string, nullable
  - `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[], nullable
    - `id` string
    - `name` string
    - `path` string
  - `tags` string[] — 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
    - `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 — 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.
    - `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.
    - `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.
    - `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 `200`

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.
  - `created_at` integer, nullable — Unix epoch when the resource was created.
  - `enabled` boolean, nullable — Whether the plugin is applied.
  - `id` string, nullable
  - `instance_name` string, nullable
  - `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[], nullable
    - `id` string
    - `name` string
    - `path` string
  - `tags` string[] — 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
    - `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 — 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.
    - `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.
    - `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.
    - `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

## Changes

> 7 revisions in range; 1 not diffed.

- **2025-04-04** `e07a25288f1f` — 2 breaking, 1 warning, 10 info
  - added `#/components/schemas/PluginBase` to the request body `allOf` list
  - request body became required
  - removed `#/components/schemas/Plugin` from the request body `allOf` list
  - added the new optional request property `allOf[#/components/schemas/OasValidationPluginConfig]/consumer`
  - …9 more
- **2024-11-26** `99e71588eb61` — 4 breaking, 1 warning, 25 info
  - added the new required request property `allOf[#/components/schemas/Plugin]/config`
  - added the new required request property `allOf[#/components/schemas/Plugin]/name`
  - the `allOf[#/components/schemas/Plugin]/` request property type changed from no type to `object`
  - the `allOf[#/components/schemas/Plugin]/` response's property type changed from no type to `object` for status `200`
  - …26 more
- **2024-09-11** `5bd52189d290` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/kong/apis/kong-enterprise-admin-api/changes/plugins/:PluginId#OasValidation/put.md)

---

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