# title
Schema definition for extra_config of workflows

# 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.sequential_propagated_params.description
The list of parameters you want to propagate from a previous response to the next request. Parameters are accessible by Lua scripts, CEL, security policies, the body generator, or plugins. When you add a `resp`-like parameter in this list, the parameter becomes available to the components mentioned in subsequent calls, **uppercasing the first letter**. For instance, if you add `resp0_user`, you can access in the second, third, etc. backends in Lua to `req:params('Resp0_user')`.The format of the parameters must start with `respX_` or `respX`, where `X` is the backend index from which you want to take the parameter. If you don't set the underscore `_`, you set the whole payload as a parameter. For instance, `resp0` sets a parameter `Resp0` to use in Lua or a Body generator and contains **the entire payload of the backend 0** (as a string). In this extreme case, you must use `no-op` in the backend's output (even the endpoint has a `json` output encoding) and you should access the value in Lua or a plugin. Note that access to **nested parameters** uses a single string with the dot notation inside, e.g.: `req_params['Resp0_f1.f2.f3']` (CEL and Security Policies), or `{{ index .req_params "Resp0_f1.f2.f3" }}` (body generators).

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

# properties.proxy.properties.sequential_propagated_params.items.description
A `resp`-like string that references the field you want to set a parameter and use it in the next backend call.

# 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.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.9/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.9/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.9/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.9/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.9/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.9/modifier/jmespath.js.title
 JMESPath: Response manipulation with query language

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

# definitions.https://schemas.sourcemeta.com/krakend/v2.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/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.9/validation/cel.json.title
Common Expression Language (CEL) validations

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