# description
A backend object is an array of all the services that an endpoint connects to. It defines the list of hostnames that connects to and the URL to send or receive the data.

# properties.allow.description
**Only return the fields in the list**. Only the matching fields (case-sensitive) are returned in the final response. Use a dot `.` separator to define nested attributes, e.g.: `a.b` removes `{"a":{"b": true}}` 

See: https://www.krakend.io/docs/backends/data-manipulation/

# properties.deny.description
**Don't return the fields in the list**. All matching fields (case-sensitive) defined in the list, are removed from the response. Use a dot `.` separator to definr nested attributes, e.g.: `a.b` removes `{"a":{"b": true}}`.

See: https://www.krakend.io/docs/backends/data-manipulation/

# properties.disable_host_sanitize.description
Set it to `true` when the host doesn't need to be checked for an HTTP protocol. This is the case of `sd=dns` or when using other protocols like `amqp://`, `nats://`, `kafka://`, etc. When set to true, and the protocol is not HTTP, KrakenD fails with an `invalid host` error.

# properties.encoding.description
Defines your [needed encoding](https://www.krakend.io/docs/backends/supported-encodings/) to set how to parse the response. Defaults to the value of its endpoint's `encoding`, or to `json` if not defined anywhere else.

See: https://www.krakend.io/docs/backends/supported-encodings/

# properties.extra_config.description
When there is additional configuration related to a specific component or middleware (like a circuit breaker, rate limit, etc.), it is declared under this section.

# properties.group.description
Instead of placing all the response attributes in the root of the response, create a new key and encapsulate the response inside.

See: https://www.krakend.io/docs/backends/data-manipulation/

# properties.host.description
An array with all the available hosts to [load balance](https://www.krakend.io/docs/throttling/load-balancing/#balancing-egress-traffic-to-upstream) requests, including the schema (when possible) `schema://host:port`. E.g.: ` https://my.users-ms.com`. If you are in a platform where hosts or services are balanced (e.g., a K8S service), write a single entry in the array with the service name/balancer address. Defaults to the `host` declaration at the configuration's root level, and the service fails starting when there is none.

# properties.is_collection.description
Set to true when your API does not return an object {} but a collection []

See: https://www.krakend.io/docs/backends/data-manipulation/

# properties.mapping.description
Mapping, or also known as renaming, let you change the name of the fields of the generated responses, so your composed response would be as close to your use case as possible without changing a line on any backend.

See: https://www.krakend.io/docs/backends/data-manipulation/

# properties.method.description
The method sent to this backend in **uppercase**. The method does not need to match the endpoint's method. When the value is omitted, it uses the same endpoint's method. Some special methods will require you to use no-op encoding (like HEAD or OPTIONS) when these return an empty body.

See: https://www.krakend.io/docs/backends/

# properties.sd.description
The [Service Discovery](https://www.krakend.io/docs/backends/service-discovery/) system to resolve your backend services. Defaults to `static` (no external Service Discovery). Use `dns` to use DNS SRV records.

See: https://www.krakend.io/docs/backends/

# properties.target.description
Removes the matching object from the reponse and returns only its contents.

See: https://www.krakend.io/docs/backends/data-manipulation/

# properties.url_pattern.description
The path inside the service (no protocol, no host, no method). E.g: `/users`. Some functionalities under `extra_config` might drop the requirement of declaring a valid `url_pattern`, but they are exceptions. The URL must be RESTful, if it is not (e.g.: `/url.{some_variable}.json`), then see how to [disable RESTful checking](#disable-restful-checking).

See: https://www.krakend.io/docs/backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/auth/client-credenti.description
2-legged OAuth2 flow: Request to your authorization server an access token to reach protected resources.

See: https://www.krakend.io/docs/authorization/client-credentials/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/auth/client-credenti.properties.client_id.description
The Client ID provided to the Auth server

See: https://www.krakend.io/docs/authorization/client-credentials/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/auth/client-credenti.properties.client_secret.description
The secret string provided to the Auth server.

See: https://www.krakend.io/docs/authorization/client-credentials/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/auth/client-credenti.properties.endpoint_params.description
Any additional parameters you want to include **in the payload** when requesting the token. For instance, adding the `audience` request parameter may denote the target API for which the token should be issued.

See: https://www.krakend.io/docs/authorization/client-credentials/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/auth/client-credenti.properties.token_url.description
The endpoint URL where the negotiation of the token happens

See: https://www.krakend.io/docs/authorization/client-credentials/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.description
The AMQP component allows to send and receive messages to and from a queue through the API Gateway.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.auto_ack.description
When KrakenD retrieves the messages, regardless of the success or failure of the operation, it marks them as `ACK`nowledge.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.delete.description
Setting to `false` is recommended to avoid deletions when the consumer is disconnected.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.durable.description
Durable queues will survive server restarts and remain when there are no remaining consumers or bindings. `true` is recommended, but depends on the use case. 

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.exchange.description
The exchange name (must have a **topic** type if already exists).

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.no_local.description
The no_local flag is not supported by RabbitMQ.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.no_wait.description
When true, do not wait for the server to confirm the request and immediately begin deliveries. If it is not possible to consume, a channel exception will be raised and the channel will be closed.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.prefetch_count.description
The number of messages you want to prefetch prior to consume them.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.prefetch_size.description
The number of bytes you want to use to prefetch messages.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/consume.properties.routing_key.description
The list of routing keys you will use to consume messages.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.description
Send messages to a queue through the API Gateway.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.delete.description
false is recommended to avoid deletions when the consumer is disconnected.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.durable.description
true is recommended, but depends on the use case. Durable queues will survive server restarts and remain when there are no remaining consumers or bindings.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.exchange.description
The exchange name (must have a topic type if already exists).

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.immediate.description
A consumer must be connected to the queue when true. Defaults to false.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.mandatory.description
The exchange must have at least one queue bound when true. Defaults to false.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.no_local.description
The no_local flag is not supported by RabbitMQ.

See: https://www.krakend.io/docs/backends/amqp-consumer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.no_wait.description
When true, do not wait for the server to confirm the request and immediately begin deliveries. If it is not possible to consume, a channel exception will be raised and the channel will be closed.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.prefetch_count.description
The number of messages you want to prefetch prior to consume them.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.prefetch_size.description
The number of bytes you want to use to prefetch messages.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/amqp/produce.properties.routing_key.description
The routing key you will use to send messages, case sensitive.

See: https://www.krakend.io/docs/backends/amqp-producer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/graphql.json.properties.type.description
The type of query you are declaring, `query` (read), or `mutation` (write).

See: https://www.krakend.io/docs/backends/graphql/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/graphql.json.properties.operationName.description
A meaningful and explicit name for your operation, required in multi-operation documents and for helpful debugging and server-side logging.

See: https://www.krakend.io/docs/backends/graphql/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/graphql.json.properties.query.description
An inline GraphQL query you want to send to the server. Use this attribute for simple and inline queries, use `query_path` instead for larger queries. Use escaping when needed.

See: https://www.krakend.io/docs/backends/graphql/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/graphql.json.properties.query_path.description
Path to the file containing the query. This file is loaded during startup and never checked again, if it changes KrakenD will be unaware of it.

See: https://www.krakend.io/docs/backends/graphql/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/graphql.json.properties.variables.description
A dictionary defining all the variables sent to the GraphQL server. You can use `{placeholders}` to inject parameters from the endpoint URL.

See: https://www.krakend.io/docs/backends/graphql/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/lambda.json.description
Invoke Amazon Lambda functions on a KrakenD endpoint call.

See: https://www.krakend.io/docs/backends/lambda/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/lambda.json.properties.endpoint.description
An optional parameter to customize the Lambda endpoint to call. Useful when Localstack is used for testing instead of direct AWS usage.

See: https://www.krakend.io/docs/backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/lambda.json.properties.function_name.description
Name of the lambda function as saved in the AWS service. You have to choose between function_name and function_param_name but not both.

See: https://www.krakend.io/docs/backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/lambda.json.properties.function_param_name.description
The endpoint {placeholder} that sets the function name. You have to choose between function_name and function_param_name but not both.

See: https://www.krakend.io/docs/backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/lambda.json.properties.max_retries.description
Maximum times you want to execute the function until you have a successful response. The value -1 defers the max retry setting to the service specific configuration.

See: https://www.krakend.io/docs/backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/lambda.json.properties.region.description
The AWS identifier region (e.g.: us-east-1, eu-west-2, etc.)

See: https://www.krakend.io/docs/backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/pubsub/publi.description
Publishes to a topic using the desired driver.

See: https://www.krakend.io/docs/backends/pubsub/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/pubsub/publi.properties.topic_url.description
Topic URL according to the selected driver

See: https://www.krakend.io/docs/backends/pubsub/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/pubsub/subsc.description
Subscribes a backend using the desired driver.

See: https://www.krakend.io/docs/backends/pubsub/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/pubsub/subsc.properties.subscription_url.description
Subscription URL according to the selected driver

See: https://www.krakend.io/docs/backends/pubsub/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/soap.json.description
Enterprise only. Build and modify requests to communicate with SOAP services.

See: https://www.krakend.io/docs/backends/soap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/soap.json.properties.content_type.description
The `Content-Type` used in your template, and that will be sent to the SOAP server. This is not the content-type the end-user sent in the request.

See: https://www.krakend.io/docs/backends/soap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/soap.json.properties.debug.description
When `true`, shows useful information in the logs with `DEBUG` level about the input received and the body generated. Do not enable in production. Debug logs are multiline and designed fore developer readibility, not machine processing.

See: https://www.krakend.io/docs/backends/soap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/soap.json.properties.path.description
The path to the Go template file you want to use to craft the body.

See: https://www.krakend.io/docs/backends/soap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend/soap.json.properties.template.description
An inline base64 encoded Go template with the body XML content you want to send to the SOAP service. This option is useful if you don't want to rely on external files and embed the template in the configuration.

See: https://www.krakend.io/docs/backends/soap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend_extra_config.properties.backend/http.properties.return_error_code.description
Returns the HTTP status code of the backend (when there is only one). The headers are not returned.

See: https://www.krakend.io/docs/backends/detailed-errors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend_extra_config.properties.backend/http.properties.return_error_details.description
Returns to the client details of a failing request.

See: https://www.krakend.io/docs/backends/detailed-errors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend_extra_config.properties.modifier/martian.description
Transform requests and responses through a simple DSL definition in the configuration file.

See: https://www.krakend.io/docs/backends/martian/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend_extra_config.properties.qos/http-cache.description
Enable in-memory caching for backend responses for as long as its Cache-Control header permits.

See: https://www.krakend.io/docs/backends/caching/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/backend_extra_config.properties.qos/http-cache.properties.shared.description
The `shared` cache makes that different backend definitions with this flag enabled can reuse the cache. When the `shared` flag is missing or set to false, the backend uses its own cache private context.

See: https://www.krakend.io/docs/backends/detailed-errors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/body-genera.description
Enterprise only. Crafts the body sent to the backend service using user input and other variables through a templating system.

See: https://www.krakend.io/backends/body-generator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/body-genera.properties.content_type.description
The `Content-Type` used in your template, and that will be sent to the backend service. This is not the content-type the end-user sent in the request.

See: https://www.krakend.io/docs/enterprise/backends/body-generator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/body-genera.properties.debug.description
When `true`, shows useful information in the logs with `DEBUG` level about the input received and the body generated. Do not enable in production. Debug logs are multiline and designed fore developer readibility, not machine processing.

See: https://www.krakend.io/docs/enterprise/backends/body-generator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/body-genera.properties.path.description
The path to the Go template file you want to use to craft the body.

See: https://www.krakend.io/docs/enterprise/backends/body-generator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/body-genera.properties.template.description
An inline base64 encoded Go template with the body content you want to send to the backend service. This option is useful if you don't want to rely on external files and embed the template in the configuration.

See: https://www.krakend.io/docs/enterprise/backends/body-generator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/jmespath.js.title
 JMESPath: Response manipulation with query language

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/jmespath.js.description
The JMESPath query language allows you to select, slice, filter, map, project, flatten, sort, and all sorts of operations on data.

See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/jmespath.js.properties.expr.description
The JMESPath expression you want to apply to this endpoint.

See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.description
Scripting with Lua is an additional choice to extend your business logic, and is compatible with the rest of options such as CEL, Martian, or other Go plugins and middlewares.

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.allow_open_libs.description
As an efficiency point the Lua component does not load the standard libraries by default. If you need to import Lua libraries (e.g, the I/O, String, etc.), then you must set this flag to true.

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.live.description
For security and efficiency, the Lua script is loaded once into memory and not reloaded even if the file contents change. Set this flag to `true` if you want to modify the Lua script while KrakenD is running and apply the changes live (mostly during development to avoid the snippet being cached).

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.md5.description
The md5sum is an extra security feature to make sure that once you have coded the Lua script, the MD5 of what is loaded into memory matches what you expect and has not been tampered by a malicious 3rd party.

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.post.description
The Lua code that is executed **after** performing the request. Available when used in the `backend` section. You can write all the Lua code inline (e.g., `print('Hi'); print('there!')` but you can also call functions that live inside one of the files under `sources` (e.g., `my_function()`).

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.pre.description
The Lua code that is executed **before** performing the request. Unlike `post`, it's available in all sections. You can write all the Lua code inline (e.g., `print('Hi'); print('there!')` but you can also call functions that live inside one of the files under `sources` (e.g., `my_function()`).

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.pre.examples[]
print('Backend response, pre-logic:'); local r = request.load(); print(r:body());

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.skip_next.description
Available on the `backend` section only. Instead of connecting to next backend in the pipe, returns an empty response and executes the `post` lua function.

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/modifier/lua.json.properties.sources.description
An array with all the Lua files that will be processed. If no path is provided (e.g., `myfile.lua`) the file loads from the working directory (same place you loaded the configuration, usually `/etc/krakend`)

See: https://www.krakend.io/docs/endpoints/lua/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/content-repla.description
Enterprise only. The content replacer plugin allows you to modify the response of your services by doing literal replacements or more sophisticated replacements with regular expressions.

See: See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/content-repla.additionalProperties.properties.find.description
The find expression or literal you want to use.

See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/content-repla.additionalProperties.properties.regexp.description
When you are passing regular expressions instead of literal values, set it to true.

See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/content-repla.additionalProperties.properties.replace.description
The literal string or expression you want to use as a replacement.

See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/http-client.j.properties.name.description
The name of the plugin to load. Only one plugin is supported per backend.

See: https://www.krakend.io/docs/extending/injecting-plugins/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/ip-filter.jso.description
Enterprise only. The IP filtering plugin allows you to restrict the traffic to your API gateway based on the IP address. It works in two different modes (allow or deny) where you define the list of IPs (CIDR blocks) that are authorized to use the API, or that are denied from using the API.

See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/ip-filter.jso.properties.CIDR.description
The CIDR blocks (list of IPs) you want to allow or deny.

See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/ip-filter.jso.properties.allow.description
When true, only the matching IPs are able to access the content. When false, all matching IPs are discarded.

See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/ip-filter.jso.properties.client_ip_headers.description
A custom list of all headers that might contain the real IP of the client. The first matching IP in the list will be used. Default headers are (in order of checking): X-Forwarded-For, X-Real-IP, and X-Appengine-Remote-Addr.

See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/ip-filter.jso.properties.trusted_proxies.description
A custom list of all the recognized machines/balancers that proxy the client to your application. This list is used to avoid spoofing when trying to get the real IP of the client.

See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/req-resp-modi.properties.name.description
An array with the names of plugins to load. The names are defined inside your plugin.

See: https://www.krakend.io/docs/extending/plugin-modifiers/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/response-sche.description
Enterprise only. The response schema validator plugin adds a schema validation before the gateway returns the response to the end-user or before it’s merged in the endpoint with the rest of the backends.

See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/response-sche.properties.error.description
In case the validation fails, the error definition containing body and status.

See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/response-sche.properties.error.examples[].body
We couldn't process you request, try again later.

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/response-sche.properties.error.properties.body.description
The error message you want to show when the validation fails. Set it to an empty string `""` to show the JSON-schema validation error.

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/response-sche.properties.error.properties.status.description
The HTTP status code you want to set back in the response.

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/plugin/response-sche.properties.schema.description
Write your JSON schema directly in this field, with any number of fields or validations you need.

See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/proxy.json.properties.flatmap_filter.description
The list of operations to **execute sequentially** (top down). Every operation is defined with an object containing two properties:

See: https://www.krakend.io/docs/backends/flatmap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/proxy.json.properties.shadow.description
Mark this backend as a shadow backend. Sending copies of the traffic but ignore its responses.

See: https://www.krakend.io/docs/backends/shadow-backends/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/proxy/flatmap.json.description
The flatmap middleware allows you to manipulate collections (or arrays, or lists, you name it) from the backend response. While the basic manipulation operations allow you to work directly with objects, the collections require a different approach: the flatmap component.

See: https://www.krakend.io/docs/backend/flatmap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/proxy/flatmap.json.items.properties.type.description
The types of operations are defined as follows.

See: https://www.krakend.io/docs/backends/flatmap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/proxy/flatmap.json.items.properties.args.description
The arguments passed to the operation.

See: https://www.krakend.io/docs/backends/flatmap/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/circuit-breaker..description
The circuit breaker prevents sending more traffic to a failing backend.

See: https://www.krakend.io/docs/backends/circuit-breaker/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/circuit-breaker..properties.interval.description
Time window where the errors count, in seconds.

See: https://www.krakend.io/docs/backends/circuit-breaker/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/circuit-breaker..properties.log_status_change.description
Whether to log the changes of state of this circuit breaker or not.

See: https://www.krakend.io/docs/backends/circuit-breaker/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/circuit-breaker..properties.max_errors.description
The **consecutive** number of errors within the `interval` window to consider the backend unhealthy. An error is any response without a success (20x) status code or no response.

See: https://www.krakend.io/docs/backends/circuit-breaker/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/circuit-breaker..properties.name.description
A friendly name to follow this circuit breaker's activity in the logs.

See: https://www.krakend.io/docs/backends/circuit-breaker/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/circuit-breaker..properties.timeout.description
For how many seconds the circuit breaker will wait before testing again if the backend is healthy.

See: https://www.krakend.io/docs/backends/circuit-breaker/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/ratelimit/proxy..description
Restrict the rate of requests KrakenD makes to your backends.

See: https://www.krakend.io/docs/backends/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/ratelimit/proxy..properties.capacity.description
The capacity according to the [token bucket algorithm](https://www.krakend.io/docs/throttling/token-bucket/) with a `bucket capacity == tokens added per second` so KrakenD is able to allow some bursting on the request rates. Recommended value is `capacity == max_rate`.

See: https://www.krakend.io/docs/backends/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/qos/ratelimit/proxy..properties.max_rate.description
Maximum requests per second you want to accept in this backend. Use decimals for per-hour and per-minute strategies.

See: https://www.krakend.io/docs/backends/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.description
The policies engine allows you to write custom sets of policies that are validated during requests, responses, or token validation.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.auto_join_policies.description
When true, all policies of the same type concatenate with an AND operation to evaluate a single expression. Performs faster, but its harder the debug.

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.debug.description
When true, all the inputs and evaluation results are printed in the console.

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.disable_macros.description
Advanced macros can be disabled in those policies not needing them for a faster evaluation.

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.jwt.description
All the policies applied in the JWT context (token validation). **You must configure `auth/validator`** for the policies to run, otherwise they will be skipped. Any policy failing will generate a `401 Unauthorized` error. Works in `endpoint` context only, this option is **not available under `backend`**.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.jwt.properties.policies.description
An array with all the policies to evaluate. Each policy is represented as a string

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.req.description
All the policies applied in the request context.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.req.properties.error.properties.body.description
Leave an empty string to use the validation error, or write a string with the error response body. This error is NOT returned in the response, but in the application logs, unless you enable `return_detailed_errors` in the `router` section. You can add escaped JSON, XML, etc in the string and add a Content-Type.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.req.properties.error.properties.content_type.description
The Content-Type header you'd like to send with the error response. When unset, uses `text/plain` by default.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.req.properties.error.properties.status.description
The HTTP status code you want to return when the validation fails.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.req.properties.policies.description
An array with all the policies to evaluate. Each policy is represented as a string

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.resp.description
All the policies applied in the response context.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.resp.properties.error.properties.body.description
Leave an empty string to use the validation error, or write a string with the error response body. This error is NOT returned in the response, but in the application logs, unless you enable `return_detailed_errors` in the `router` section. You can add escaped JSON, XML, etc in the string and add a Content-Type.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.resp.properties.error.properties.content_type.description
The Content-Type header you'd like to send with the error response. When unset, uses `text/plain` by default.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.resp.properties.error.properties.status.description
The HTTP status code you want to return when the validation fails.

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/security/policies.js.properties.resp.properties.policies.description
An array with all the policies to evaluate. Each policy is represented as a string

See: https://www.krakend.io/docs/enterprise/security-policies/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/validation/cel.json.title
Common Expression Language (CEL) validations

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/validation/cel.json.description
The Common Expression Language (CEL) middleware enables expression evaluation, when an expression returns false, KrakenD does not return the content as the condition has failed. Otherwise, if all expressions returned true, the content is served.

See: https://www.krakend.io/docs/endpoints/common-expression-language-cel/

# definitions.https://schemas.sourcemeta.com/krakend/v2.2/validation/cel.json.items.properties.check_expr.description
The expression that evaluates as a boolean, you can write here any conditional. If the result of the expression is `true`, the execution continues. See in the docs how to use additional variables to retrieve data from requests, responses, and tokens.

See: https://www.krakend.io/docs/endpoints/common-expression-language-cel/