# title
Schema definition for extra_config of endpoints

# properties.auth/api-keys.description
Enterprise only. Validates that users of this endpoint pass a valid API-key containing one of the declared roles.

See: https://www.krakend.io/docs/enterprise/authentication/api-keys/

# properties.auth/api-keys.properties.client_max_rate.description
If you want to limit the endpoint usage to this specific user at a number of requests per second. Exceeding the number of requests per second will give the client a `429 Too Many Requests` HTTP status code.

See: https://www.krakend.io/docs/enterprise/authentication/api-keys/

# properties.auth/api-keys.properties.identifier.description
The header name or the query string name that contains the API key. By default uses any value declared in the `auth/api-keys` component in the service level.

See: https://www.krakend.io/docs/enterprise/authentication/api-keys/

# properties.auth/api-keys.properties.roles.description
The list of roles allowed to access the endpoint. Values must match (case sensitive) definitions in the `keys` section at the service level of `auth/api-keys`. API Keys not having the right role, or unauthenticated requests, will receive a `401 Unauthorized`.

See: https://www.krakend.io/docs/enterprise/authentication/api-keys/

# properties.auth/api-keys.properties.strategy.description
Specifies where to expect the user API key, whether inside a header or as part of the query string. When you change the strategy at the endpoint level, **you should also set the identifier**, otherwise you could have for instance, a query string strategy expecting to have a URL like `/foo?Authorization=YOUR-KEY`.

See: https://www.krakend.io/docs/enterprise/authentication/api-keys/

# properties.proxy.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/

# properties.proxy.properties.sequential.description
The sequential proxy allows you to chain backend requests, making calls dependent one of each other.

See: https://www.krakend.io/docs/endpoints/sequential-proxy/

# properties.proxy.properties.static.description
The static proxy injects static data in the final response when the selected strategy matches.

See: https://www.krakend.io/docs/endpoints/static-proxy/

# properties.proxy.properties.static.properties.data.description
The static data (as a JSON object) that you will return.

See: https://www.krakend.io/docs/endpoints/static-proxy/

# properties.qos/ratelimit/router.description
The router rate limit feature allows you to set a number of maximum requests per second a KrakenD endpoint will accept.

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

# properties.validation/json-schema.title
Validating the body with the JSON Schema

# properties.validation/json-schema.description
apply automatic validations using the JSON Schema vocabulary before the content passes to the backends. The json schema component allows you to define validation rules on the body, type definition, or even validate the fields' values.

See: https://www.krakend.io/docs/endpoints/json-schema/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/basic.json.description
Enterprise only. The Basic Authentication component protects the access to selected endpoints using basic username and password credentials.

See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/basic.json.properties.htpasswd_path.description
Absolute Path to the `htpasswd` filename (recommended) or relative `./` to the workdir (less secure).

See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/basic.json.properties.users.description
**Additional** users to the `htpasswd` file can be declared directly inside the configuration. The content of both places will be merged (and this list will overwrite users already defined in the htpasswd file). The key of each entry is the username, and the value the bcrypt.

See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.description
creates a wrapper for your login endpoint that signs with your secret key the selected fields of the backend payload right before returning the content to the end-user.

See: https://www.krakend.io/docs/authorization/jwt-signing/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.alg.description
The hashing algorithm used by the issuer. Usually `RS256`. The algorithm you choose directly affects the CPU consumption.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.cipher_suites.description
Override the default cipher suites (see [JWT validation](https://www.krakend.io/docs/authorization/jwt-validation/)). Unless you have a legacy JWK, **you don't need to set this value**.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.disable_jwk_security.description
Disables HTTP security of the JWK client and allows insecure connections (plain HTTP) to download the keys. The flag should be `false` when you use HTTPS, and `true` when using plain HTTP or loading the key from a local file.

See: https://www.krakend.io/docs/enterprise/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.full.description
Use JSON format instead of the compact form JWT provides.

See: https://www.krakend.io/docs/enterprise/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.jwk_fingerprints.description
A list of fingerprints (the unique identifier of the certificate) for certificate pinning and avoid man in the middle attacks. Add fingerprints in base64 format.

See: https://www.krakend.io/docs/authorization/jwt-signing/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.jwk_local_ca.description
Path to the CA’s certificate verifying a secure connection when downloading the JWK. Use when not recognized by the system (e.g., self-signed certificates).

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.jwk_local_path.description
Local path to the JWK public keys, has preference over `jwk_url`. Instead of pointing to an external URL (with `jwk_url`), public keys are kept locally, in a plain JWK file (security alert!), or encrypted. When encrypted, also add `secret_url` and `cypher_key`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.jwk_url.description
 The URL to the JWK endpoint with the private keys used to sign the token.

See: https://www.krakend.io/docs/authorization/jwt-signing/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.keys_to_sign.description
List of all the specific keys that need signing (e.g., `refresh_token` and `access_token`).

See: https://www.krakend.io/docs/authorization/jwt-signing/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/signer.json.properties.kid.description
The key ID purpose is to match a specific key, as the jwk_url might contain several keys.

See: https://www.krakend.io/docs/enterprise/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.description
Protect endpoints from public usage by validating JWT tokens generated by any industry-standard OpenID Connect (OIDC) integration.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.alg.description
The hashing algorithm used by the token issuer.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.audience.description
Reject tokens that do not contain ALL audiences declared in the list.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.auth_header_name.description
Allows to parse the token from a custom header.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.cache.description
Set this value to `true` (recommended) to stop downloading keys on every request and store them in memory for the next `cache_duration` period and avoid hammering the key server, as recommended for performance. Do not use this flag when using `jwk_local_ca`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.cache_duration.description
The cache duration in seconds when the `cache` is enabled. 15 minutes when unset.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.cipher_suites.description
Override the default cipher suites. Use it if you want to enforce an even higher security standard.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.cookie_key.description
Add the key name of the cookie containing the token when it is not passed in the headers

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.disable_jwk_security.description
When true, disables security of the JWK client and allows insecure connections (plain HTTP) to download the keys. Useful for development environments.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.issuer.description
When set, tokens not matching the issuer are rejected.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.jwk_fingerprints.description
A list of fingerprints (the certificate's unique identifier) for certificate pinning and avoid man-in-the-middle attacks. Add fingerprints in base64 format.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.jwk_local_ca.description
Path to the CA's certificate verifying a secure connection when downloading the JWK. Use when not recognized by the system (e.g., self-signed certificates).

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.jwk_local_path.description
Local path to the JWK public keys, has preference over `jwk_url`. Instead of pointing to an external URL (with `jwk_url`), public keys are kept locally, in a plain JWK file (security alert!), or encrypted. When encrypted, also add `secret_url` and `cypher_key`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.jwk_url.description
The URL to the JWK endpoint with the public keys used to verify the token's authenticity and integrity. Use with `cache` to avoid re-downloading the key on every request. Consider enabling [shared caching](https://www.krakend.io/docs/authorization/jwk-caching/) too. The identity server will receive an HTTP(s) request from KrakenD with a KrakenD user agent, and the identity server must reply with a JSON object and a content-type `application/jwk-set+json` or `application/json`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.key_identify_strategy.description
Allows strategies other than `kid` to load keys.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.leeway.description
A margin of time where you will accept an already expired token. You should not accept expired tokens other than enabling two environments that are not perfectly synchronized and have minor clock drifts to accept each other differences. Any value specified here will be rounded to seconds, with a minimum of one second.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.operation_debug.description
When `true`, any JWT **validation operation** gets printed in the log with a level `ERROR`. You will see if a client does not have sufficient roles, the allowed claims, scopes, and other useful information.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.propagate_claims.description
Enables passing claims in the backend's request header. You can pass nested claims using the dot `.` operator. E.g.: `realm_access.roles`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.roles.description
 When set, the JWT token not having at least one of the listed roles is rejected.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.roles_key.description
When validating users through roles, provide the key name inside the JWT payload that lists their roles. If this key is nested inside another object, add `roles_key_is_nested` and use the dot notation `.` to traverse each level. E.g.: `resource_access.myclient.roles` represents the payload `{resource_access: { myclient: { roles: ["myrole"] } }`. Notice that the roles object you choose is a list, not a map.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.roles_key_is_nested.description
If the roles key uses a nested object using the `.` dot notation, you must set it to `true` to traverse the object.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.scopes.description
A list of scopes to validate. The token, after decoding it, can have the scopes declared as a space-separated list, e.g.: `"my_scopes": "resource1:action1 resource3:action7"` or inside a list, e.g.: `"my_scopes": ["resource1:action1","resource3:action7"]`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.scopes_key.description
The key name where KrakenD can find the scopes. The key can be a nested object using the `.` dot notation, e.g.: `data.access.my_scopes`.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.scopes_matcher.description
Defines if the user needs to have in its token at least one of the listed claims (`any`), or `all` of them.

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/auth/validator.json.properties.secret_url.description
An URL with a custom scheme using one of the supported providers (e.g.: `awskms://keyID`) (see providers).

See: https://www.krakend.io/docs/authorization/jwt-validation/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.description.description
An introductory, optionally verbose, explanation supporting [CommonMark](http://commonmark.org/help/) syntax. If you'd like to load an **external markdown file**, you can use flexible configuration, for instance `"description": {{include "openapi/intro.md" | toJson }}`

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.audience.description
The list of audiences that will consume this endpoint. These values **do not define the gateway logic** in any way. They are a way to group endpoints and filter them out when generating the OpenAPI documentation. Use `*` to indicate an endpoint will be present in any audience generated.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.base_path.description
A starting path that is appended to any endpoint.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.components_schemas.description
The JSON Schemas you can reuse inside endpoint definitions using `ref`. You can either pass the JSON Schema object, or a bas64 string.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.contact_email.description
Email where users of your API can write to.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.contact_url.description
Contact URL that users of your API can read.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.example.description
**Deprecated in OAS3** (use `response_definition` instead). A free form JSON object or a string you would like to show as a sample response of the endpoint. The examples assume they are JSON content types except when using the `output_encoding=string`.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.host.description
The hostname where you will publish your API.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.license_url.description
The URL where the license is hosted

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.operation_id.description
A unique string identifying the operation identifier. Usually the method + the endpoint. If provided, these IDs must be unique among all operations described in your API.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.query_definition.description
Sets a description for the query strings allowed in the endpoint. Make sure to include the same strings in the endpoint's `input_query_strings`.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.query_definition.items.properties.required.description
Set to `true` when this query string is required

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.query_definition.items.properties.name.description
The name of the querystring, as declared in `input_query_strings`

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.request_definition.description
Describes the request needed to consume the endpoint. If a JSON Schema validation exists, it takes precedence when generating the documentation. An example use case is when you need to document a `multipart/form-data` request body.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.request_definition.properties.description.description
The description of the payload this endpoint accepts.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.request_definition.properties.content_type.description
The content type returned by this error, e.g., `application/json`

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.request_definition.properties.example.description
A free form JSON object or a string you would like to show as a sample response of the endpoint. The examples assume they are JSON content types except when using the `output_encoding=string`.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.request_definition.properties.example_schema.description
A JSON schema that describes the request format for the accepted payload in the endpoint. Use either example or example_schema, but not both.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.request_definition.properties.ref.description
The relative reference to the `components/schema` OpenAPI definition that will be used as definition of the accepted request. Notice that the path `#/components/schemas/` is not needed.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.response_definition.description
Describes the different status codes returned by this endpoint. Each key is the definition of the status code, represented by a string. E.g., `200` (success), `500` (internal error), etc.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.response_definition.patternProperties.default|^[0-9]+$.properties.description.description
The description of this error code, e.g., `Page not found`.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.response_definition.patternProperties.default|^[0-9]+$.properties.content_type.description
The content type returned by this error, e.g., `application/json`

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.response_definition.patternProperties.default|^[0-9]+$.properties.example.description
A free form JSON object or a string you would like to show as a sample response of the endpoint. The examples assume they are JSON content types except when using the `output_encoding=string`.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.response_definition.patternProperties.default|^[0-9]+$.properties.example_schema.description
A JSON schema that describes the response format for the endpoint, directly as a JSON object, or encoded as a base64 string. Use either example or example_schema, but not both.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.response_definition.patternProperties.default|^[0-9]+$.properties.ref.description
The relative reference to the `components/schema` OpenAPI definition that will be used as definition of the accepted request. Notice that the path `#/components/schemas/` is not needed.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.schemes.description
The list of schemes supported by the API, e.g. `http` or `https`

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.summary.description
A short summary for the endpoint. Use the description field for the longest explanation.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.tag_definition.description
Sets a description for the tags classifiying endpoints when generating the OpenAPI spec.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.tag_definition.items.properties.name.description
The name of the tag. You will use this name in each endpoint.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.tags.description
You can assign a list of tags to each API operation. If you declare tags in the `tag_definition` at the OpenAPI service level, they will have a description in the documentation. Tagged operations may be handled differently by tools and libraries. For example, Swagger UI uses tags to group the displayed operations.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.terms_of_service.description
The URL to the terms of service for using this API.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/documentation/openap.properties.version.description
The version numbering you want to apply to this release of API., e.g.: `1.0`.

See: https://www.krakend.io/docs/enterprise/developer/openapi/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/modifier/body-genera.description
Enterprise only. Crafts the body/payload using a templating system.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/modifier/body-genera.properties.content_type.description
The `Content-Type` you are generating in the template, so it can be recognized by whoever is using it.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/modifier/body-genera.properties.template.description
An inline base64 encoded Go template with the body you want to generate. This option is useful if you want to have the template embedded in the configuration instead of an external file.

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

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/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.6/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.6/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.6/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. The key of the object must match **exactly** the filename under sources, **including all the path**.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/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.6/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.6/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](https://www.krakend.io/docs/configuration/working-directory/).

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/plugin/response-sche.properties.error.examples[].body
We couldn't process you request, try again later.

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/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.6/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.6/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.6/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.6/qos/ratelimit/router.properties.capacity.description
Defines the maximum number of [tokens a bucket can hold](https://www.krakend.io/docs/throttling/token-bucket/), or said otherwise, how many requests will you accept from **all users together** at **any given instant**. When the gateway starts, the bucket is full. As requests from users come, the remaining tokens in the bucket decrease. At the same time, the `max_rate` refills the bucket at the desired rate until its maximum capacity is reached. The default value for the `capacity` is the `max_rate` value expressed in seconds or 1 for smaller fractions. When unsure, use the same number as `max_rate`.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/qos/ratelimit/router.properties.client_capacity.description
Defines the maximum number of [tokens a bucket can hold](https://www.krakend.io/docs/throttling/token-bucket/), or said otherwise, how many requests will you accept from **each individual user** at **any given instant**. Works just as `capacity`, but instead of having one bucket for all users, keeps a counter for every connected client and endpoint, and refills from `client_max_rate` instead of `max_rate`. The client is recognized using the `strategy` field (an IP address, a token, a header, etc.). The default value for the `client_capacity` is the `client_max_rate` value expressed in seconds or 1 for smaller fractions. When unsure, use the same number as `client_max_rate`.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/qos/ratelimit/router.properties.client_max_rate.description
Number of tokens you add to the [Token Bucket](https://www.krakend.io/docs/throttling/token-bucket/) for each individual user (*user quota*) in the time interval you want (`every`). The remaining tokens in the bucket are the requests a specific user can do. It keeps a counter for every client and endpoint. Keep in mind that every KrakenD instance keeps its counters in memory for **every single client**.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/qos/ratelimit/router.properties.every.description
Time period in which the maximum rates operate. For instance, if you set an `every` of `10m` and a `max_rate` of `5`, you are allowing 5 requests every ten minutes.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/qos/ratelimit/router.properties.key.description
Available when using `client_max_rate` and you have set a `strategy` of `header`. It makes no sense in other contexts. Sets the header containing the user identification (e.g., `Authorization` on tokens) or IP (e.g.,`X-Original-Forwarded-For`). When the header contains a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/qos/ratelimit/router.properties.max_rate.description
Sets the maximum number of requests all users can do in the given time frame. Internally uses the [Token Bucket](https://www.krakend.io/docs/throttling/token-bucket/) algorithm. The absence of `max_rate` in the configuration or a `0` is the equivalent to no limitation. You can use decimals if needed.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/qos/ratelimit/router.properties.strategy.description
Available when using `client_max_rate`. Sets the strategy you will use to set client counters. Choose `ip` when the restrictions apply to the client's IP address, or set it to `header` when there is a header that identifies a user uniquely. That header must be defined with the `key` entry.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/bot-detecto.description
The bot detector module checks incoming connections to the gateway to determine if a bot made them, helping you detect and reject bots carrying out scraping, content theft, and form spam.

See: https://www.krakend.io/docs/throttling/botdetector/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/bot-detecto.properties.allow.description
An array with EXACT MATCHES of trusted user agents that can connect.

See: https://www.krakend.io/docs/throttling/botdetector/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/bot-detecto.properties.cache_size.description
Size of the LRU cache that helps speed the bot detection. The size is the mumber of users agents that you want to keep in memory.

See: https://www.krakend.io/docs/throttling/botdetector/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/bot-detecto.properties.deny.description
An array with EXACT MATCHES of undesired bots, to reject immediately.

See: https://www.krakend.io/docs/throttling/botdetector/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/bot-detecto.properties.empty_user_agent_is_bot.description
Whether to consider an empty user-agent a bot (and reject it) or not. 

See: https://www.krakend.io/docs/throttling/botdetector/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/bot-detecto.properties.patterns.description
An array with all the regular expressions that define bots. Matching bots are rejected.

See: https://www.krakend.io/docs/throttling/botdetector/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.description
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.allow_credentials.description
When requests can include user credentials like cookies, HTTP authentication or client side SSL certificates.

See: https://www.krakend.io/docs/service-settings/cors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.allow_headers.description
An array with the headers allowed, but `Origin`is always appended to the list. Requests with headers not in this list are rejected.

See: https://www.krakend.io/docs/service-settings/cors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.allow_methods.description
An array with all the HTTP methods allowed, in uppercase. Possible values are `GET`, `HEAD`,`POST`,`PUT`,`PATCH`,`DELETE`, or `OPTIONS`

See: https://www.krakend.io/docs/service-settings/cors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.allow_origins.description
An array with all the origins allowed, examples of values are `https://example.com`, or `*` (any origin).

See: https://www.krakend.io/docs/service-settings/cors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.debug.description
Show debugging information in the logger, **use it only during development**.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.expose_headers.description
List of headers that are safe to expose to the API of a CORS API specification.

See: https://www.krakend.io/docs/service-settings/cors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/cors.json.properties.max_age.description
For how long the response can be cached. For zero values the `Access-Control-Max-Age` header is not set.

See: https://www.krakend.io/docs/service-settings/cors/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.description
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.allowed_hosts.description
When a request hits KrakenD, it will confirm if the value of the Host HTTP header is in the list. If so, it will further process the request. If the host is not in the allowed hosts list, KrakenD will simply reject the request.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.browser_xss_filter.title
This feature enables the Cross-site scripting (XSS) filter in the user's browser.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.content_security_policy.description
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.content_type_nosniff.description
Enabling this feature will prevent the user's browser from interpreting files as something else than declared by the content type in the HTTP headers.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.custom_frame_options_value.description
You can add an X-Frame-Options header using custom_frame_options_value with the value of DENY (default behavior) or even set your custom value.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.host_proxy_headers.description
A set of header keys that may hold a proxied hostname value for the request.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.hpkp_public_key.description
HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.).

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.is_development.description
This will cause the AllowedHosts, SSLRedirect, and STSSeconds/STSIncludeSubdomains options to be ignored during development. When deploying to production, be sure to set this to false.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.referrer_policy.description
Allows the Referrer-Policy header with the value to be set with a custom value.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.ssl_host.description
When the SSL redirect is true, the host where the request is redirected to.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.ssl_proxy_headers.description
Header keys with associated values that would indicate a valid https request. Useful when using Nginx, e.g: `"X-Forwarded-Proto": "https"`

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.ssl_redirect.description
Redirect any request that is not using HTTPS

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.sts_include_subdomains.description
Set to true when you want the `includeSubdomains` be appended to the Strict-Transport-Security header.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.sts_seconds.title
HTTP Strict Transport Security (HSTS) seconds

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/security/http.json.properties.sts_seconds.description
Enable this policy by setting the `max-age` of the `Strict-Transport-Security` header. Setting to `0` disables HSTS.

See: https://www.krakend.io/docs/service-settings/security/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/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.6/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.6/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 the `endpoint` context only, and is not available under `backend`.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/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.6/telemetry/openteleme.description
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.

See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.exporters_override.description
Override exporter configuration for this endpoint

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.exporters_override.properties.metric_exporters.description
Overrides the metrics exporters used in this endpoint

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.exporters_override.properties.metric_reporting_period.description
Override how often you want to report and flush the metrics in seconds.

See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.exporters_override.properties.trace_exporters.description
Overrides the trace exporters used in this endpoint

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.exporters_override.properties.trace_sample_rate.description
Overrides the sample rate for traces defines the percentage of reported traces. This option is key to reduce the amount of data generated (and resource usage), while you still can debug and troubleshoot issues. For instance, a number of `0.25` will report a 25% of the traces seen in the system.

See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.proxy.description
Reports the activity at the beginning of the proxy layer, including spawning the required requests to multiple backends, merging, endpoint transformation and any other internals of the proxy between the request processing and the backend communication

See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.proxy.properties.disable_metrics.description
Whether you want to disable all metrics in this endpoint or not.

See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/telemetry/openteleme.properties.proxy.properties.disable_traces.description
Whether you want to disable all traces in this endpoint or not.

See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/timeunits.json.$defs.timeunit.description
The amount of time you want to assign followed by its unit (e.g.: `2s`, `200ms`). Valid time units are: ns, us, (or µs), ms, s, m, h.

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/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.6/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/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.backoff_strategy.description
When the connection to your event source gets interrupted for whatever reason, KrakenD keeps trying to reconnect until it succeeds or until it reaches the max_retries. The backoff strategy defines the delay in seconds in between consecutive failed retries. Defaults to 'fallback'

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.connect_event.description
Whether to send notification events to the backend or not when a user establishes a new Websockets connection.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.disconnect_event.description
Whether to send notification events to the backend or not when users disconnect from their Websockets connection.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.input_headers.description
Defines which input headers are allowed to pass to the backend. Notice that you need to declare the `input_headers` at the endpoint level too.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.max_message_size.description
Sets the maximum size of messages **in bytes** sent by or returned to the client. Messages larger than this value are discarded by KrakenD and the client disconnected.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.max_retries.description
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. Use a value `<= 0` for unlimited retries.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.message_buffer_size.description
Sets the maximum number of messages **each client** can have in the buffer waiting to be processed. As this is a per-client setting, you must forecast how many consumers of KrakenD websockets you will have. The default value may be too high (memory consumption) if you expect thousands of clients consuming simultaneously.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.ping_period.description
Sets the time between pings checking the health of the system.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.pong_wait.description
Sets the maximum time KrakenD will until the pong times out.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.read_buffer_size.description
Connections buffer network input and output to reduce the number of system calls when reading messages. You can set the maximum buffer size for reading in bytes.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.return_error_details.description
Provides an error `{'error':'reason here'}` to the client when KrakenD was unable to send the message to the backend.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.write_buffer_size.description
Connections buffer network input and output to reduce the number of system calls when writing messages. You can set the maximum buffer size for writing in bytes.

See: https://www.krakend.io/docs/enterprise/websockets/

# definitions.https://schemas.sourcemeta.com/krakend/v2.6/websocket.json.properties.write_wait.description
Sets the maximum time KrakenD will wait until the write times out.

See: https://www.krakend.io/docs/enterprise/websockets/