latest--krakend
shared| Type | object |
|---|---|
| Schema URL | https://catalog.lintel.tools/schemas/schemastore/krakend/_shared/latest--krakend.json |
| Parent schema | krakend |
Properties
The syntax version tells KrakenD how to read this configuration. This is not the KrakenD version. Each KrakenD version is linked to a syntax version, and since KrakenD v2.0 the version must be 3
Async agents are routines listening to queues or PubSub systems that react to new events and push data to your backends. Through async agents, you can start a lot of consumers to process your events autonomously.
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.
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enables the /__debug/ endpoint for this configuration. You can safely enable it in production.
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.
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.
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.
When true prevents requesting compression with an Accept-Encoding: gzip request header when the Request contains no existing Accept-Encoding value. If the Transport requests gzip on its own and gets a gzipped response, it's transparently decoded. However, if the user explicitly requested gzip it is not automatically uncompressed.
See: https://www.krakend.io/docs/service-settings/http-transport-settings/
When true it disables HTTP keep-alives and will only use the connection to the server for a single HTTP request.
See: https://www.krakend.io/docs/service-settings/http-transport-settings/
Endpoints require in its endpoint definition the usage of a RESTful pattern. If you require unrestful patterns, like /file.{ext} (instead of its RESTful counterpart /file/{ext}), then you must set this parameter to true.
You can use multiple variables if needed, but only one can be in an unrestful position, and when you do, it must be in the last position of the definition. E.g.: you can declare an endpoint /file/{name}/base.{ext} but you cannot do /file.{ext}.json because the variable {ext} is not in the last position of the definitino, and therefore the remaining path after {ext} is ignored by the router.
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.
Enables the /__echo/ endpoint for this configuration, that returns information about the incoming request. When using /__echo as a backend you can check the actual headers and content a backend receives after all the zero-trust filtering.
Your API contract, or the list of all paths recognized by this gateway. The paths /__health/, /__debug/, /__echo/, /__catchall, and /__stats/ are reserved by the system and you cannot declare them. Their existence depends on their respective settings.
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.
34 nested properties
MCP functionality.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
1 nested properties
The array of MCP servers available for linking to endpoints. Each object represents a different MCP server. The entry is only the definition of the server. You must create an endpoint that serves as the entrypoint to each server.
Enterprise only. Enables a Role-Based Access Control (RBAC) mechanism by reading the Authorization header of incoming requests.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
6 nested properties
A list of objects defining each API Key.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The hashing function used to store the value of the key. When you use plain the API key is written as it will passed by the user. The rest of the hashes require you to save the API key after applying the desired function.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The header name or the query string name that contains the API key. Defaults to key when using the query_string strategy and to Authorization when using the header strategy. The identifier set here is used across all endpoints with API key authentication enabled, but they can override this entry individually.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The name of a header that will propagate to the backend containing the matching role. The backend receives no header when the string is empty, or the attribute is not declared. Otherwise, the backend receives the declared header name containing the first matching role of the user. The header value will be ANY when the endpoint does not require roles. For instance, if an API key has roles [A, B], and the endpoint demands roles [B, C], the backend will receive a header with the value B.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
A salt string for the desired hashing function. When provided, the API key is concatenated after the salt string and both hashed together.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
Specifies where to expect the user API key, whether inside a header or as part of the query string. The strategy set here is used across all endpoints with API key authentication enabled, but they can override this entry individually.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
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/
2 nested properties
Absolute Path to the htpasswd filename (recommended) or relative ./ to the workdir (less secure).
See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/
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/
The API Gateway authorizes users that provide valid tokens according to your criteria, but at some point, you might want to change your mind and decide to revoke JWT tokens that are still valid.
11 nested properties
The maximum Number of elements you want to keep in the bloom filter. Tens of millions work fine on machines with low resources.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The Probability of returning a false positive. E.g.,1e-7 for one false positive every 10 million different tokens. The values N and P determine the size of the resulting bloom filter to fulfill your expectations. E.g: 0.0000001
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The lifespan of the JWT you are generating in seconds. The value must match the expiration you are setting in the identity provider when creating the tokens.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
Either optimal (recommended) or default. The optimal consumes less CPU but has less entropy when generating the hash, although the loss is negligible.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The port number exposed on each KrakenD instance for the RPC service to interact with the bloomfilter. This port is allocated only to the clients (running KrakenDs).
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The list with all the claims in your JWT payload that need watching. These fields establish the criteria to revoke accesses in the future. The Revoker does not use this value, only the clients.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
A string used as an exchange API key to secure the communication between the Revoke Server and the KrakenD instances and to consume the REST API of the Revoker Server as well. E.g., a string generated with uuidgen.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
Maximum number of retries after a connection fails. When the value is less than zero it is changed automatically to zero.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
How many workers are used concurrently to execute an action (e.g., push a token) to all registered instances, allowing you to limit the amount of memory consumed by the server. For example, if you have 100 KrakenD servers and need to push 5MB of data each, you need to send 500MB in total. A max_workers=5 will consume a maximum of 5MB x 5 workers = 25MB of memory in a given instant. Defaults to the same number of CPUs available.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
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.
The address to the /instances endpoint in the Revoke Server.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
Enables global configurations for the HTTP client responsible of downloading and caching the JWK URLs for token validation and signing.
1 nested properties
The cache duration in seconds for the JWK client retrieving the jwk_url. The endpoint must enable the cache option in order to use this second level cache.
Enterprise only. Generates OpenAPI documentation automatically through krakend openapi export command.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
28 nested properties
An introductory, optionally verbose, explanation supporting CommonMark 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/
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/
A starting path that is appended to any endpoint.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The JSON Schemas you can reuse inside endpoint definitions using ref. You can either pass the JSON Schema object, or a bas64 string.
Email where users of your API can write to.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact name.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact URL that users of your API can read.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the cookie used under components securitySchemes.
Allows you to add custom security schemes under components/securitySchemes in the generated OpenAPI spec. This is useful when you want to define your own security schemes, different from the built-in ones (e.g., jwt, apikey, cookie, etc.). When the property is in the service level you must declare the schema (e.g., "OAuth2Security":{...}), and when it is in the endpoint you should only write the object name with not properties inside, e.g, {"OAuth2Security":{}.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
By default, KrakenD adds a 500 and a 200 response definition to each endpoint. Set this property to true if you want to avoid this behavior.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the headers allowed in the endpoint. Make sure to include the same headers in the endpoint's input_headers.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The hostname where you will publish your API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the JWT key used under components securitySchemes.
The license name (e.g.: Apache License)
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The URL where the license is hosted
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the URL parameters (e.g.: /foo/{param}) required in the endpoint. Make sure to include to write the param exactly as in the endpoint definition.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed 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/
Describes the payload 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.This property is an array because you can document requests with multiple content types.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The list of schemes supported by the API, e.g. http or https
See: https://www.krakend.io/docs/enterprise/developer/openapi/
[
"http"
]The list of servers where the API is hosted. The server URL can be a relative path, e.g., /v1 or an absolute path. The URL might contain {variables}, although these are only recognized by OpenAPI and to KrakenD they are just literal strings because it does not use them.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
A short summary for the endpoint. Use the description field for the longest explanation.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed description for the tags classifiying endpoints when generating the OpenAPI spec.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The URL to the terms of service for using this API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Enterprise only. Generates postman documentation automatically through krakend postman export command.
See: https://www.krakend.io/docs/enterprise/developer/postman/
4 nested properties
An introductory, optionally verbose, explanation supporting Markdown syntax. If you'd like to load an external markdown file, you can use flexible configuration, for instance "description": {{include "postman/intro.md" | toJson }}
See: https://www.krakend.io/docs/enterprise/developer/postman/
The folder definition where you will add endpoints
The name of the Postman collection you are generating.
See: https://www.krakend.io/docs/enterprise/developer/postman/
The version you assign to this Postman collection you are generating using semantic versioning.
See: https://www.krakend.io/docs/enterprise/developer/postman/
Declares rules and limits to be enforced.
1 nested properties
The list of quota processors available for attachment. You can have multiple processors with different configurations.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
7 nested properties
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. gRPC server integration
2 nested properties
The paths to the different .pb files you want to load, or the paths to directories containing .pb files. All content is scanned in the order of the list, and after fetching all files it resolves the dependencies of their imports. The order you use here is not important to resolve imports, but it matters when there are conflicts (different files using the same namespace and package type).
Defines the gRPC server properties.
2 nested properties
Overrides OpenTelemetry settings for the gRPC server.
Defines one object per available gRPC service.
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
1 nested properties
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Enterprise only. Allows you to transform response headers declaratively.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
4 nested properties
The headers you want to add. Every key under add is the header name, and the values are declared in an array with all those you want to set. If the header didn't exist previously, it is created with the values you passed. If the header existed, then the new values are appended.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The list of headers you want to delete. All headers listed will be missing in the response.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to rename. The key used under rename is the original header name, and the value the new header name. This operation is destructive, meaning that if you rename to a header name that already existed it will be replaced with the new header and value.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to replace. The key used under replace is the header name, and the value an array with all the header values you want to set. The replacement overwrites any other value that could exist in this header.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
9 nested properties
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/extending/http-server-plugins/
[]Enterprise only. The GeoIP integration allows you load Maxmind's GeoIP2 City database (payment and free versions) and enrich all KrakenD calls to your backends with geo data.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
1 nested properties
The path in the filesystem containing the database in GeoIP2 Binary (.mmdb) format. Relative to the working dir or absolute path.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
Enterprise only. The JWK aggregator plugin allows KrakenD to validate tokens issued by multiple Identity Providers.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
3 nested properties
The list of all JWK URLs recognized as valid Identity Providers by the gateway.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
The port of the local server doing the aggregation. The port is only accessible within the gateway machine using localhost, and it's never exposed to the external network. Choose any port that is free in the system.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
When true, it stores the response of the Identity provider for the time specified in its Cache-Control header.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
Enterprise only. The global rate limit functionality enables a Redis database store to centralize all KrakenD node counters. Instead of having each KrakenD node count its hits, the counters are global and stored in the database.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
6 nested properties
How many requests a client can make above the rate specified during a peak.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The URL to the Redis instance that stores the counters using the format host:port.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
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.
Number of allowed requests during the observed period.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
One of the preselected strategies to rate-limit users.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The field used to set a custom field for the tokenizer (e.g., extracting the token from a custom header other than Authorization or using a claim from a JWT other than the jti).
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
Enterprise only. Allows you to fetch and serve static content in two different use cases. When the plugin is used as an http server handler, the static content is for your end-users, giving them CSS, JS, images, or JSON files, to name a few examples. On the other side, when the plugin is used as an http client executor, the KrakenD endpoints use static content as if it were a backend.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
3 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. Allows you to declare additional URLs other than the ones defined under the endpoints configuration, used as aliases of existing endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
2 nested properties
A map with the exact desired url and its mapping to an endpoint. If the endpoint has {placeholders} you need to write them, but the literal value {placeholders} is passed.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
A list of lists, containing the regular expression that defines the URL to be rewritten, and its endpoint destination. You can use the capturing groups with the syntax ${1}, ${2}, etc.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
Enterprise only. The Virtual Host plugin allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
1 nested properties
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Enterprise only. Enables wildcard processing of requests without declaring all endpoint subresrouces.
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
1 nested properties
The key of the map is the KrakenD endpoint that receives all the wildcard traffic. The value is an array with all the user paths that match this wildcard (you don't need to declare the subresources).
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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.
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.
These are the number of routines that search for and remove outdated rate limit counters. The more routine(s) you add, the faster the memory optimization is completed, but the more CPU it will consume. Generally speaking, a single thread is more than enough because the delete operation is very fast, even with a large number of counters. This is an advanced micro-optimization setting that you should use with caution.
Defines the maximum number of tokens a bucket can hold, 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.
Number of tokens you add to the 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.
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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.
All rate limit counters are stored in memory in groups (shards). All counters in the same shard share a mutex (which controls that one counter is modified at a time), and this helps with contention. Having, for instance, 2048 shards (default) and 1M users connected concurrently (same instant) means that each user will need to coordinate writes in their counter with an average of under 500 other users (1M/2048=489). Lowering the shards might increase contention and latency but free additional memory. This is an advanced micro-optimization setting that should be used with caution.
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.
Enterprise only. Redis-backed service ratelimit
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Number of tokens you add to the 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/enterprise/throttling/global-rate-limit/
The connection pool name or cluster name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
The connection pool name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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/enterprise/throttling/global-rate-limit/
Whether you want to allow a request to continue when the Redis connection is failing or not. The default behavior blocks the request if Redis is not responding correctly
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/enterprise/throttling/global-rate-limit/
Enterprise only. Apply ratelimit based on tier match.
2 nested properties
The header name containing the tier name. The string you provide is case-insensitive. If you need to take the value from a place that is not a header (a token, an API key), you must use propagate functions in the components that convert values to internal headers.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
The list of all tier definitions and limits for each. Each item in the list is a tier object.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
Defines the Redis connection pools available to any functionality requiring Redis.
See: /docs/enterprise/throttling/global-rate-limit/
2 nested properties
Defines all the clusters available to Redis functionality. The different components requiring Redis will access the pool based on its name
Defines all the connetion pools available to Redis functionality. The different components requiring Redis will access the pool based on its name
The optional router configuration allows you to set global flags that change the way KrakenD processes the requests at the router layer.
See: https://www.krakend.io/docs/service-settings/router-options/
21 nested properties
The app_engine boolean trusts headers starting with X-AppEngine... for better integration with that PaaS.
See: https://www.krakend.io/docs/service-settings/router-options/
When true, enables the autogenerated OPTIONS endpoint for all the registered paths
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Decompresses any Gzipped content before sending it to the backend when the Content-Encoding has gzip in the first position. You can also set this value per endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
Stops registering access requests to KrakenD in the logs. You can still have a Backend Log if needed.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. All the output to the end user on the Enterprise Edition uses gzip when accepted by the client. Use this flag to remove gzip compression.
See: https://www.krakend.io/docs/service-settings/router-options/
Whether to checks if another method is allowed for the current route, if the current request can not be routed. If this is the case, the request is answered with Method Not Allowed and HTTP status code 405. If no other Method is allowed, the request is a 404.
See: https://www.krakend.io/docs/service-settings/router-options/
When true you don't have any exposed health endpoint. You can still use a TCP checker or build an endpoint yourself.
See: https://www.krakend.io/docs/service-settings/router-options/
Disables automatic validation of the url params looking for url encoded ones.
See: https://www.krakend.io/docs/service-settings/router-options/
If true, the router tries to fix the current request path, if no handle is registered for it
See: https://www.krakend.io/docs/service-settings/router-options/
Disables automatic redirection if the current route can't be matched but a handler for the path with (without) the trailing slash exists. Only works if disable_redirect_fixed_path is also set to true.
See: https://www.krakend.io/docs/service-settings/router-options/
Sets custom error bodies for 404 and 405 errors.
See: https://www.krakend.io/docs/service-settings/router-options/
2 nested properties
Write any JSON object structure you would like to return to users when they request an endpoint not known by KrakenD. 404 Not Found errors.
Write any JSON object structure you would like to return to users
When set to true, the client IP will be parsed from the default request's headers, or the custom ones (remote_ip_headers). If the IP has passed through a trusted proxy (e.g.: a proxy, load balancer, or a third party application) it will be extracted. If no IP can be fetched, it falls back to the IP obtained from the request's remote address. When declared you must configure trusted_proxies too.
See: https://www.krakend.io/docs/service-settings/router-options/
The path where you'd like to expose the health endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
Removes the version of KrakenD used in the X-KrakenD-version headers.
See: https://www.krakend.io/docs/service-settings/router-options/
Defines the set of paths that are removed from the logging.
See: https://www.krakend.io/docs/service-settings/router-options/
Sets the maxMemory param that is given to http.Request's Multipart Form method call.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Limits the maximum number of bytes a user can send to the gateway. 0 means no limit. You can also set this value per endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
List of headers used to obtain the client IP when forwarded_by_client_ip is set to true and the remote address is matched by at least one of the network origins of trusted_proxies.
See: https://www.krakend.io/docs/service-settings/router-options/
A parameter can be parsed from the URL even with extra slashes.
See: https://www.krakend.io/docs/service-settings/router-options/
When there is an error in the gateway (such as a timeout, a non-200 status code, etc.) it returns to the client the reason for the failure. The error is written in the body as is.
See: https://www.krakend.io/docs/service-settings/router-options/
List of network origins (IPv4 addresses, IPv4 CIDRs, IPv6 addresses or IPv6 CIDRs) from which to trust request's headers that contain alternative client IP when forwarded_by_client_ip is true. When declared you must configure forwarded_by_client_ip set to true, and optionally remote_ip_headers.
See: https://www.krakend.io/docs/service-settings/router-options/
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.
5 nested properties
An array with EXACT MATCHES of trusted user agents that can connect.
[]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.
An array with EXACT MATCHES of undesired bots, to reject immediately.
[]Whether to consider an empty user-agent a bot (and reject it) or not.
An array with all the regular expressions that define bots. Matching bots are rejected.
[]When KrakenD endpoints are consumed from a browser, you might need to enable the Cross-Origin Resource Sharing (CORS) module as browsers restrict cross-origin HTTP requests initiated from scripts.
{
"allow_methods": [
"POST",
"GET"
],
"allow_origins": [
"http://foobar.com"
],
"max_age": "12h"
}7 nested properties
An array with all the origins allowed, examples of values are https://example.com, or * (any origin).
When requests can include user credentials like cookies, HTTP authentication or client side SSL certificates
[]The array of all HTTP methods accepted, in uppercase.
Show debugging information in the logger, to be used only during development.
Headers that are safe to expose to the API of a CORS API specification-
[]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.
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.
17 nested properties
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.
[]Treat the allowed hosts list as regular expressions.
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
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.
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.
Force a STS Header even if using plain HTTP.
Set to true to enable clickjacking protection, together with custom_frame_options_value.
A set of header keys that may hold a proxied hostname value for the request.
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.).
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.
Allows the Referrer-Policy header with the value to be set with a custom value.
When the SSL redirect is true, the host where the request is redirected to.
Header keys with associated values that would indicate a valid https request. Useful when using Nginx, e.g: "X-Forwarded-Proto": "https"
Redirect any request that is not using HTTPS
Set to true when you want the includeSubdomains be appended to the Strict-Transport-Security header.
Enable this policy by setting the max-age of the Strict-Transport-Security header. Setting to 0 disables HSTS.
Enterprise only. Allows you to fetch and serve static content by registering a static web server for a set of defined paths (the prefixes).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
4 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Whether to allow directory listings or not
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. The Virtual Host server allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
2 nested properties
A map of all recognized virtual hosts where the key is the alias and the value the host name, including the port if it's not 443 or 80. The values declared here must match the content of the Host header passed by the client. The alias must be an alphanumeric string.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
1 nested properties
The key of this map must compile with the regexp a-z0-9_ and the host name is the string that matches the value sent by the user in the Host header.
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Send structured events in GELF format to your Graylog Cluster.
2 nested properties
The address (including the port) of your Graylog cluster (or any other service that receives GELF inputs). E.g., myGraylogInstance:12201
Set to false (recommended) to use UDP, or true to use TCP. TCP performance is worst than UDP under heavy load.
Enables the extended logging capabilities.
6 nested properties
The complete url of the influxdb including the port if different from defaults in http/https.
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.
The buffer size is a protection mechanism that allows you to temporarily store datapoints for later reporting when Influx is unavailable. If the buffer is 0, reported metrics that fail are discarded immediately. If the buffer is a positive number, KrakenD creates a buffer with the number of datapoints set. When the buffer is full because the Influx server keeps failing, newer datapoints replace older ones in the buffer.
Name of the InfluxDB database (Influx v1) or the bucket name (Influx v2).
Password to authenticate to InfluxDB. In Influx v2, you also need to add grant access with influx v1 auth.
Username to authenticate to InfluxDB.
Enables the extended logging capabilities.
11 nested properties
What type of reporting level do you expect from the application? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
Specify the format of the application logs: default, logstash, or custom. The custom format needs an additional key "custom_format".
Enterprise only. You can write the access log pattern you would like to use. Add a newline \n at the end of the pattern. See the variables you can use.
Enterprise only. Enable a formatter for the access log. You can write your own pattern using the custom value, or you can use one of the predefined ones.
Enterprise only. When you use a custom access log format, the variable you are trying to print could be empty. For instance, you have added in the format %{header.Authorization} but the header is missing in the request. In this case, the printed value is what you configure here. If the string is set to an empty value, a dash - is printed.
Enables the Backend Log capabilities.
4 nested properties
Specify the custom format of the Backend Logs.
What type of reporting level do you want to set at the backends? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
When the variable does not resolve to any value, the string you want to write in the log. If the string is set to an empty value, a dash - is printed.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on.
Lets you write a custom logging pattern using variables, e.g: %{message}.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on. It's recommended to always add a prefix [INSIDE BRACKETS] to make use of predefined dashboards.
Set to true to send logs to stdout.
Set to true to send logs to syslog.
When using syslog, the facility tells KrakenD where to send the messages as set by the locals of the syslog standard.
Enables logstash when the extra_config "telemetry/logging" is also present.
1 nested properties
Collects extended metrics to push to InfluxDB or expose them in the /__stats/ endpoint.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
6 nested properties
Skip any metrics happening in the backend layer. Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
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.
When true do not publish the /__stats/ endpoint. Metrics won't be accessible via the endpoint but still collected (and you can send them to Influx for instance).
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Change the listening address where the metrics endpoint is exposed.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the proxy layer (traffic against your backends). Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the router layer (activity in KrakenD endpoints). Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
The Moesif integration helps you understand and monetize API usage with a robust analytics and billing platform.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
15 nested properties
The Collector Application ID is used to send events, actions, users, and companies to Moesif's Collector API. Moesif provides it under the 'API Keys' section.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Defines the list of possible headers that can identify a user uniquely. When the header is Authorization, it automatically extracts the username if it contains an Authorization: Basic value with no additional configuration. If, on the other hand, you use tokens and pass an Authorization: Bearer, it will extract the user ID from the JWT claim defined under user_id_jwt_claim. If there are multiple headers in the list, all of them are tested in the given order, and the first existing header in the list is used to extract the user ID (successfully or not).
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Number of events you will send on every batch reporting asynchronously to Moesif. For high throughput you will need to increase this value.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Set to true when configuring Moesif for the first time while in development, to see the activity in the logs. Set to false in production.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Sends the number of events you can hold in-memory to send them asynchronously to Moesif. If the throughput of your API generates more events than the size of the queue, the exceeding events will be discarded and not reported.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
It sets which strategy you want to use to identify the company. Identifying the company helps you efficiently govern your API. Choose the system you wish to apply (declare only one property). The claim value you access must be of type string. You can access nested structured using the dot . separator. When using dots, literals with an exact match containing the dot are checked first.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
3 nested properties
The company is identified using a header. Provide the header name.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The company is stored in a claim inside the JWT. The claim must return a string.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The company is always passed inside a query string when calling any URL. Provide the query string name.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Send the body of all endpoints and requests to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
A free-form object that allows you to push custom metadata along with events. The custom metadata appears in Moesif under a key krakend, you can use nesting if needed.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of fields in the request body that you want to mask before sending them to Moesif. You can set log_body to false to prevent any body being sent.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of request headers that you want to mask their values before sending them to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of fields in the response body that you want to mask before sending them to Moesif. You can set log_body to false to prevent any body being sent.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of response headers that you want to mask their values before sending them to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Defines an expression expressed as Security Policy that avoids reporting to Moesif when the result of the evaluation is true.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Specifies how often a background thread runs to send events to Moesif. Value in seconds.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
When using JWT tokens, it defines which claim contains the user ID. The claim value you access must be of type string. You can access nested structured using the dot . separator. When using dots, literals with an exact match containing the dot are checked first.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The New Relic integration lets you push KrakenD metrics and distributed traces to your New Relic dashboard. It uses internally the official New Relic SDK and brings its features to your APM dashboard.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
3 nested properties
The API key provided by New Relic to push data into your account.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Set to true when configuring New Relic for the first time while in development, to see the activity in the logs. Set to false in production.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Defines an explicit list of headers sent during the client request that will be reported to NewRelic, in addition to the default headers NewRelic sets. Setting the ["*"] value will send all headers sent by the client to NewRelic. Whether you declare this setting or not, you will usually receive from the NewRelic SDK the Accept, Content-Type, User-Agent, and Referer headers.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Enables the extended logging capabilities.
4 nested properties
The exporter(s) you would like to enable. See each exporter configuration in its own section.
9 nested properties
Datadog is a monitoring and security platform for developers, IT operations teams and business in the cloud.
Exports data to InfluxDB: A time series database designed to handle high write and query loads.
Submit spans to a Jaeger Collector (HTTP) with endpoint or to a Jaeger Agent (UDP) with agent_endpoint.
Opencensus can export data to the system logger as another exporter. Recommended to use telemetry/logging instead.
Exporting metrics, logs, and events to the OpenCensus Agent.
Prometheus is an open-source systems monitoring and alerting toolkit.
Export metrics and traces to Google Cloud
AWS X-Ray is a service offered by Amazon that provides an end-to-end view of requests as they travel through your application, and shows a map of your application's underlying components.
Export telemetry data to a Zipkin collector
Lets you specify what data you want to export. All layers are enabled by default unless you declare this section.
3 nested properties
Reports the activity between KrakenD and your services
Reports the activity at the beginning of the proxy layer. It gives a more detailed view of the internals of the pipe between end-users and KrakenD, having into account merging of different backends.
Reports the activity between end-users and KrakenD
The number of seconds passing between reports. If duration is less than or equal to zero, it enables the default behavior of each exporter.
A number between 0 (no requests at all) and 100 (all requests) representing the percentage of sampled requests you want to send to the exporter. Sampling the 100% of the requests is generally discouraged when the relationship between traffic and dedicated resources is sparse.
Enables metrics and traces using OpenTelemetry.
9 nested properties
The places where you will send telemetry data. You can declare multiple exporters even when they are of the same type. For instance, when you have a self-hosted Grafana and would like to migrate to its cloud version and check the double reporting during the transition. There are two families of exporters: otlp or prometheus.
2 nested properties
The list of OTLP exporters you want to use. Set at least one object to push metrics and traces to an external collector using OTLP.
Set here at least the settings for one Prometheus exporter. Each exporter will start a local port that offers metrics to be pulled from KrakenD.
The environment you are deploying, this can be useful for deployment tracking. The string can have any value that makes sense to you to identify the running environment.
Use an histogram bucket configuration different from the defaults to define the detail of histogram metrics (decrease or increase their size). You don't need to set this attribute unless you want full control of the histogram definition.
2 nested properties
The size of the buckets in bytes you want to use for the histograms.
[
128,
256,
512,
1024,
4096,
8192,
16384,
32768,
65536,
262144,
524288,
1048576,
4194304,
16777216,
67108864
]The duration of buckets in seconds you want to use for the histograms.
[
0.01,
0.02,
0.05,
0.075,
0.1,
0.125,
0.15,
0.175,
0.2,
0.25,
0.3,
0.35,
0.5,
0.75,
1.0,
1.5,
2.0,
3.5,
5.0,
10.0
]A request and response flow passes through three different layers. This attribute lets you specify what data you want to export in each layer. All layers are enabled by default unless you declare this section.
3 nested properties
Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
Reports the activity between end-users and KrakenD
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
How often you want to report and flush the metrics in seconds. This setting is only used by otlp exporters.
A friendly name identifying metrics reported by this installation. When unset, it uses the name attribute in the root level of the configuration.
The version you are deploying, this can be useful for deployment tracking.
The paths you don't want to report. Use the literal value used in the endpoint definition, including any {placeholders}. In the global layer, this attribute works only on metrics, because traces are initiated before there is an endpoint to match against. If you do not want any path skipped, just add an array with an empty string [""].
[
"/__health",
"/__debug/",
"/__echo/",
"/__stats/"
]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.
Enables the security layer needed to use OpenTelemetry through the Internet, like pushing data to a SaaS provider.
See: https://www.krakend.io/docs/telemetry/opentelemetry-security/
1 nested properties
The list of OTLP exporters that require authentication. Set at least one object to push metrics and traces to an external collector using OTLP.
See: https://www.krakend.io/docs/telemetry/opentelemetry-security/
The default host list for all backends if they specify none.
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.
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.
The IP address that KrakenD listens to in IPv4 or IPv6. An empty string, or no declaration at all means listening on all interfaces. The inclusion of :: is meant for IPv6 format only (this is not the port). Examples of valid addresses are 192.0.2.1 (IPv4), 2001:db8::68 (IPv6). The values :: and 0.0.0.0 listen to all addresses and both are valid for IPv4 and IPv6 simultaneously.
Allows overriding the maximum size of headers sent in bytes. It does not limit the request body. When the value is zero, the default is used instead (1MB)
See: https://www.krakend.io/docs/service-settings/http-transport-settings/
The maximum number of idle (keep-alive) connections across all hosts. Zero means no limit.
See: https://www.krakend.io/docs/service-settings/http-transport-settings/
If non-zero, controls the maximum idle (keep-alive) connections to keep per-host. If zero, 250 is used instead.
See: https://www.krakend.io/docs/service-settings/http-transport-settings/
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.
Used in telemetry. A friendly name, title, date, version or any other short description that helps you recognize the configuration.
The encoding used to display the content to the end-user. This setting is the default for all endpoints, unless they have another output_encoding overrinding this value.
Enables external plugins that are copied in a specific folder
2 nested properties
The pattern narrows down the contents of the folder. It represents the substring that must be present in the plugin name to load.
The path in the filesystem where all the plugins you want to load are. MUST END IN SLASH. The folder can be a relative or absolute path. KrakenD Enterprise uses /opt/krakend/plugins/ for all plugins.
The TCP port where KrakenD is listening to. Recommended value is in the range 1024-65535 to run as an unpriviliged user
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.
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.
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.
A sequential start registers all async agents in order, allowing you to have the starting logs in sequential order. A non-sequential start is much faster, but logs are harder to follow.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
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.
Enabling TLS for HTTPS and HTTP/2.
9 nested properties
An array with all the CA certificates you would like to load to KrakenD when using mTLS, in addition to the certificates present in the system's CA. Each certificate in the list is a relative or absolute path to the PEM file. If you have a format other than PEM, you must convert the certificate to PEM using a conversion tool. See also disable_system_ca_pool to avoid system's CA.
See: https://www.krakend.io/docs/authorization/mutual-authentication/
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
A flag to disable TLS (useful while in development).
Whether to enable or not Mutual Authentication. When mTLS is enabled, all KrakenD endpoints require clients to provide a known client-side X.509 authentication certificate. KrakenD relies on the system’s CA to validate certificates.
See: https://www.krakend.io/docs/authorization/mutual-authentication/
An array with all the key pairs you want the TLS to work with. You can support multiple and unrelated domains in a single process.
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enable the support for HTTP/2 with no TLS. This option is only advised when you have a load balancer in front of KrakenD doing SSL termination, and you have no option to enable SSL communication between the balancer and KrakenD (no internal certificates available either). Otherwise, enabling this flag is less secure and less performant.
See: https://www.krakend.io/docs/service-settings/router-options/
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
Connect to Anthropic models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
5 nested properties
Your Anthropic API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
The variables specific to the Anthropic usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
7 nested properties
The name of the Anthropic model you want to use.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
A map of additional payload attributes you want to use in your custom input_template (this payload is not used in the default template). The attributes set here are accessible in your custom template as {{ .variables.extra_payload.yourchosenkey }}. This option helps adding rare customization and future attributes.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Maximum number of tokens that can be generated in the response. A token is approximately four characters. 100 tokens correspond to roughly 60-80 words.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
An array of sequences where the model will stop generating further tokens if found. This can be useful to control the length and content of the output.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
The temperature is used for sampling during response generation, which occurs when topP and topK are applied. Temperature controls the degree of randomness in token selection. Lower temperatures are good for prompts that require a less open-ended or creative response, while higher temperatures can lead to more diverse or creative results.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Top-K changes how the model selects tokens for output. A top-K of 1 means the next selected token is the most probable among all tokens in the model's vocabulary (also called greedy decoding), while a top-K of 3 means that the next token is selected from among the three most probable tokens by using temperature.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Top-P changes how the model selects tokens for output. Tokens are selected from the most probable to least probable until the sum of their probabilities equals the top-P value. For example, if tokens A, B, and C have a probability of 0.3, 0.2, and 0.1 and the top-P value is 0.5, then the model will select either A or B as the next token by using temperature and excludes C as a candidate.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
A path to a custom Go template that sets the payload format sent to Anthropic. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
A path to a custom Go template that sets how the response from Anthropic is transformed before being sent to the client. The default template extracts the text from the first choice returned by Anthropic so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Connect to Bedrock models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
5 nested properties
Your Bedrock API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
The variables specific to the Bedrock usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
6 nested properties
A map of additional payload attributes you want to use in your custom input_template (this payload is not used in the default template). The attributes set here are accessible in your custom template as {{ .variables.extra_payload.yourchosenkey }}. This option helps adding rare customization and future attributes.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
An upper bound for the number of tokens that can be generated for a response, including visible output tokens and reasoning tokens.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
An array of sequences where the model will stop generating further tokens if found. This can be useful to control the length and content of the output.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
What sampling temperature to use, recommended between 0.0 and 0.7. Higher values like 0.7 will make the output more random, while lower values like 0.2 will make it more focused and deterministic. Change this or top_p but not both.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Top-K changes how the model selects tokens for output. A top-K of 1 means the next selected token is the most probable among all tokens in the model's vocabulary (also called greedy decoding), while a top-K of 3 means that the next token is selected from among the three most probable tokens by using temperature.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
A float value between 0 and 1 that controls the nucleus sampling for text generation. It represents the cumulative probability threshold for token selection, where only the most probable tokens that add up to this threshold are considered. A higher value (closer to 1) allows for more diverse outputs, while a lower value (closer to 0) makes the output more focused and deterministic. Change this or temperature but not both.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
A path to a custom Go template that sets the payload format sent to Bedrock. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
A path to a custom Go template that sets how the response from Bedrock is transformed before being sent to the client. The default template extracts the text from the first choice returned by Bedrock so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Connect to Google Gemini models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
5 nested properties
Your Google Gemini API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
A path to a custom Go template that sets the payload format sent to Google Gemini. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
A path to a custom Go template that sets how the response from Google Gemini is transformed before being sent to the client. The default template extracts the text from the first choice returned by Google Gemini so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
The variables specific to the Google Gemini usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
7 nested properties
An integer value that specifies how many different completions (responses) the model should generate for a single input prompt. This can be useful for exploring multiple variations of the output.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
A map of additional payload attributes you want to use in your custom input_template (this payload is not used in the default template). The attributes set here are accessible in your custom template as {{ .variables.extra_payload.yourchosenkey }}. This option helps adding rare customization and future attributes.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Maximum number of tokens that can be generated in the response. A token is approximately four characters. 100 tokens correspond to roughly 60-80 words.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
An array of sequences where the model will stop generating further tokens if found. This can be useful to control the length and content of the output.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
The temperature is used for sampling during response generation, which occurs when topP and topK are applied. Temperature controls the degree of randomness in token selection. Lower temperatures are good for prompts that require a less open-ended or creative response, while higher temperatures can lead to more diverse or creative results.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Top-K changes how the model selects tokens for output. A top-K of 1 means the next selected token is the most probable among all tokens in the model's vocabulary (also called greedy decoding), while a top-K of 3 means that the next token is selected from among the three most probable tokens by using temperature.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Top-P changes how the model selects tokens for output. Tokens are selected from the most probable to least probable until the sum of their probabilities equals the top-P value. For example, if tokens A, B, and C have a probability of 0.3, 0.2, and 0.1 and the top-P value is 0.5, then the model will select either A or B as the next token by using temperature and excludes C as a candidate.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Connect to Mistral models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
5 nested properties
Your Mistral API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
The variables specific to the Mistral usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
9 nested properties
The name of the Mistral model you want to use. The value you provide is passed as is to Mistral and KrakenD does not prove if the model is currently accepted by the vendor. Check the available models on Mistral documentation.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A map of additional payload attributes you want to use in your custom input_template (this payload is not used in the default template). The attributes set here are accessible in your custom template as {{ .variables.extra_payload.yourchosenkey }}. This option helps adding rare customization and future attributes.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
An upper bound for the number of tokens that can be generated for a response, including visible output tokens and reasoning tokens.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
An integer value that specifies how many different completions (responses) the model should generate for a single input prompt. This can be useful for exploring multiple variations of the output.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
An integer value to seed the random number generator used by the model. Setting a specific seed can help produce reproducible results across different requests.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A boolean flag to enable or disable Mistral's safe prompt feature, which helps filter out inappropriate or harmful content from the model's responses. By default, this feature is enabled to ensure safer interactions.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
An array of sequences where the model will stop generating further tokens if found. This can be useful to control the length and content of the output.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
What sampling temperature to use, recommended between 0.0 and 0.7. Higher values like 0.7 will make the output more random, while lower values like 0.2 will make it more focused and deterministic. Change this or top_p but not both.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A float value between 0 and 1 that controls the nucleus sampling for text generation. It represents the cumulative probability threshold for token selection, where only the most probable tokens that add up to this threshold are considered. A higher value (closer to 1) allows for more diverse outputs, while a lower value (closer to 0) makes the output more focused and deterministic. Change this or temperature but not both.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A path to a custom Go template that sets the payload format sent to Mistral. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A path to a custom Go template that sets how the response from Mistral is transformed before being sent to the client. The default template extracts the text from the first choice returned by Mistral so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
Connect to OpenAI's GPT models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
5 nested properties
Your OpenAI API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
The variables specific to the OpenAI usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
6 nested properties
The name of the OpenAI model you want to use. The value you provide is passed as is to OpenAI and KrakenD does not prove if the model is currently accepted by the vendor. Check the available models on OpenAI documentation.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
A map of additional payload attributes you want to use in your custom input_template (this payload is not used in the default template). The attributes set here are accessible in your custom template as {{ .variables.extra_payload.yourchosenkey }}. This option helps adding rare customization and future attributes.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
An upper bound for the number of tokens that can be generated for a response, including visible output tokens and reasoning tokens. Setting this value to 0 does not set any limit.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
The nucleus sampling, where the model considers the results of the tokens with top_p probability mass. So 0.1 means only the tokens comprising the top 10% probability mass are considered.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
The strategy to use when truncating messages to fit within the model's context length (, the model will truncate the response to fit the context window by dropping items from the beginning of the conversation.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
A path to a custom Go template that sets the payload format sent to OpenAI. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
A path to a custom Go template that sets how the response from OpenAI is transformed before being sent to the client. The default template extracts the text from the first choice returned by OpenAI so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
Ready-to-use LLM connectors available for major AI vendors.
See: https://www.krakend.io/docs/enterprise/ai-gateway/unified-llm-interface/
Connect to Anthropic models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
5 nested properties
Your Anthropic API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
The variables specific to the Anthropic usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
A path to a custom Go template that sets the payload format sent to Anthropic. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
A path to a custom Go template that sets how the response from Anthropic is transformed before being sent to the client. The default template extracts the text from the first choice returned by Anthropic so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Connect to Google Gemini models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
5 nested properties
Your Google Gemini API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
A path to a custom Go template that sets the payload format sent to Google Gemini. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
A path to a custom Go template that sets how the response from Google Gemini is transformed before being sent to the client. The default template extracts the text from the first choice returned by Google Gemini so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
The variables specific to the Google Gemini usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Connect to Mistral models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
5 nested properties
Your Mistral API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
The variables specific to the Mistral usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A path to a custom Go template that sets the payload format sent to Mistral. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
A path to a custom Go template that sets how the response from Mistral is transformed before being sent to the client. The default template extracts the text from the first choice returned by Mistral so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
Connect to OpenAI's GPT models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
5 nested properties
Your OpenAI API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
The variables specific to the OpenAI usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
A path to a custom Go template that sets the payload format sent to OpenAI. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
A path to a custom Go template that sets how the response from OpenAI is transformed before being sent to the client. The default template extracts the text from the first choice returned by OpenAI so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
Connect to Bedrock models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
5 nested properties
Your Bedrock API key. You can set it as an environment variable for better security.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
The variables specific to the Bedrock usage that are used to construct the payload.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Enables the debug mode to log activity for troubleshooting. Do not set this value to true in production as it may log sensitive data.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
A path to a custom Go template that sets the payload format sent to Bedrock. You don't need to set this value unless you want to override the default template making use of all the variables listed in this configuration.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
A path to a custom Go template that sets how the response from Bedrock is transformed before being sent to the client. The default template extracts the text from the first choice returned by Bedrock so in most cases you don't need to set a custom output template.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Enterprise only. Enables AWS Sigv4 authentication between KrakenD and Google Cloud service account.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The AWS region where the service is deployed.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The name of the service in AWS you'd like to sign the request.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The Amazon Resource Name (ARN) of the role to assume.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
Enables debug logging for AWS Sigv4 signing process.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The AWS region where the STS service is deployed.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
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/
The Client ID provided to the Auth server
See: https://www.krakend.io/docs/authorization/client-credentials/
The secret string provided to the Auth server.
See: https://www.krakend.io/docs/authorization/client-credentials/
The endpoint URL where the negotiation of the token happens
See: https://www.krakend.io/docs/authorization/client-credentials/
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/
A comma-separated list of scopes needed, e.g.: scopeA,scopeB
See: https://www.krakend.io/docs/authorization/client-credentials/
Enterprise only. Enables GCP authentication between KrakenD and Google Cloud service account.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The audience in GCP looks like an URL, and contains the destination service you will ask a token for. Most of the times this URL will match exactly with the host entry.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The relative or absolute path to a credentials file in JSON format that contains all the credentials to authenticate API calls to the given service account.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
An inline JSON object containing all the credentials fields to authenticate to GCP.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
Custom private claims that you can optionally add to an ID token.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The header name to use in service-to-service authentication. This is useful to honor the original Authorization header in case it's needed by the backend (for example, CloudRun).
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
Enterprise only. Enables NTLM authentication between KrakenD and a Microsoft server such as Dynamics.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The password you will use, in clear text.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The username you will send as NTLM authentication user.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The AMQP component allows to send and receive messages to and from a queue through the API Gateway.
The exchange name (must have a topic type if already exists).
Queue name.
The list of routing keys you will use to consume messages.
When KrakenD retrieves the messages, regardless of the success or failure of the operation, it marks them as ACKnowledge.
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. Check the meaning of each strategy.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
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.
When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries.
When true, messages that cannot be processed are discarded instead of being sent back to the queue. This is useful for scenarios where you want to avoid reprocessing failed messages.
The no_local flag is not supported by RabbitMQ.
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.
The number of messages you want to prefetch prior to consume them.
Send messages to a queue through the API Gateway.
The exchange name (must have a topic type if already exists).
Queue name.
The routing key you will use to send messages, case sensitive.
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. Check the meaning of each strategy.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
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.
When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
Take a parameter from a {placeholder} in the endpoint definition to use as the expiration key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
A consumer must be connected to the queue when true.
The exchange must have at least one queue bound when true.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries.
Take a parameter from a {placeholder} in the endpoint definition to use as the message identifier. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
The no_local flag is not supported by RabbitMQ.
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.
Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
Defines whether the routing_key will have a static value or not, instead of taking the value from a parameter.
Evaluates a rule to determine if the backend is callable or not, and skip to the next one in case it's not.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Choose header when you want to check the value of a specific header, policy when you want to write a more complex logical expression, or fallback when the backend will execute when all the rest of conditional backends have failed to evaluate to true. Only one fallback can be defined per endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Only used with the header strategy. It is the name of the header you want to use for the evaluation in the canonical format of the MIME header. Make sure to declare the header in the input_headers list of the endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
The value according to the strategy. With the header strategy, this is the literal value contained in the header (case sensitive). With the policy strategy, the Security Policy expression. When using policies you can access to the variables req and req_params (a previous backend response might be in the latter), and to advanced macros. Access to headers require you to add the corresponding input_headers in the endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Convert REST endpoints to GraphQL calls (adapter/transformer)
The type of query you are declaring, query (read), or mutation (write).
A meaningful and explicit name for your operation, required in multi-operation documents and for helpful debugging and server-side logging.
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.
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.
A dictionary defining all the variables sent to the GraphQL server. You can use {placeholders} to inject parameters from the endpoint URL.
TLS options to connect to upstream services.
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enterprise only. Handles the communication with a backend using gRPC, after having defined the protocol buffer definitions.
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
When true, it does not use URL parameters ({placeholders} in endpoints) or query strings to fill the gRPC payload to send. If use_request_body is not set, or set to false, and this option is set to true, there will be no input used for the gRPC message to send. That is still a valid option, when we just want to send the message with its default values, or when the input for the gRPC calls is just the empty message.
A dictionary that rename the received header (key) to a new header name (value). If the header starts with grpc they will be renamed to in-grpc-* as the word is reserved.
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.
When set to true, when the backend has to fill a bytes field for a grpc protobuf payload to send, first tries to decode the input data (the one coming from either a json body field, a query param or header string) from base64: if it succeeds it fills the field to send with that binary / bytes data. If the incoming field is not a valid base64 decoded field (the one used in jsonpb), it will fill the binary field with the verbatim conversion of the incoming string to bytes.
A dictionary that converts query string parameters and parameters from {placeholders} into a different field during the backend request. When passing parameters using {placeholder} the parameter capitalizes the first letter, so you receive Placeholder.
Specifies the maximum size (in bytes) for messages the grpc client is allowed to receive. If the value is unset, or 0, it uses its default (4MB)
Well-known Duration types (google.protobuf.Duration) are returned as a struct containing fields with seconds and nanos fields (flag set to false). Setting this flag to true transforms the timestamps into a string representation in seconds.
Enum types are returned as numeric values (flag set to false). Set this flag to true to return the string representation of the enum value. For instance, an enum representing allergies, such as ['NUTS', 'MILK', ' SOY', 'WHEAT'] would return a value SOY when this flag is true, or 2 when false.
This attribute defines what to do when a field that is declared in the definition does not exist in the backend response. When the flag is true, any fields in the definition that are not present in the backend response are removed before returning the content to the user. When the flag is false missing fields are returned but set with a zeroed-value depending on its type (zero, nil, false, etc).
Well-known Timestamp types (google.protobuf.Timestamp) are returned as a struct containing fields with seconds and nanos fields (flag set to false). Setting this flag to true transforms the timestamps into a string representation in RFC3999 format.
Specifies the size of the client buffer reading the gRPC communication in bytes. If the value is unset, or 0, it uses its default (32KB). Use a negative value to disable the buffer, and if you do there won't be memory pre-allocation to read. To determine the right number, calculate the average size of the responses the gRPC client will receive.
Defines the naming convention used to format the request. Applies to query strings and JSON field names. By default, the gateway uses snake_case which makes use of the standard encoding/json package, while when you choose camelCase the protobuf/encoding deserialization is used instead.
Defines the naming convention used to format the returned data. By default, the gateway uses snake_case which makes use of the standard encoding/json package, while when you choose camelCase the protobuf/encoding deserialization is used instead.
When true, before sending a message to a host, it checks if the connection status is in a "transient failure" or "failure" state and tries to use a different host (from the service discovery or randomly from the list of hosts). If the connection is in a valid state, but an error happens when sending the gRPC message, it also tries to use a different host to retry sending the message. Depending on the host list, the retry attempts may go to the same host initially in a "bad state".
Enables the use of the sent body to fill the gRPC request. Take into account that when you set this flag to true a body is expected, and this body is consumed in the first backend. If the endpoint that uses this gRPC backend has additional backends (either gRPC or HTTP) that also expect to consume the payload, these requests might fail.
Enterprise only. Allows you to set the different HTTP client options with the backend, like TLS, no redirect or connect via a proxy.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Set no_redirect to true if you don't want KrakenD to follow redirects and let the consuming user to receive the 30x status code.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
The proxy address used to forward the traffic. The address must contain the protocol and the port.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
Post the original body to the final URL after a 307 or a 308 redirection.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
Invoke Amazon Lambda functions on a KrakenD endpoint call.
An optional parameter to customize the Lambda endpoint to call. Useful when Localstack is used for testing instead of direct AWS usage.
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.
The endpoint {placeholder} that sets the function name, with the first letter uppercased. You have to choose between function_name and function_param_name but not both. If your endpoint defines the route /foo/{bar} the value of function_param_name must be Bar with the uppercased B.
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.
The AWS identifier region
Publishes to a topic using the desired driver.
Topic URL according to the selected driver
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
Name of the enabled SASL mechanism
Kafka > 1.x should use SASL V1, except on Azure EventHub which uses V0
Whether or not to send the Kafka SASL handshake first if enabled. You should only set this to false if you're using a non-Kafka SASL proxy
Auth Identity is an (optional) authorization identity (authzid) to use for SASL/PLAIN authentication (if different from User) when an authenticated user is permitted to act as the presented alternative user. See RFC4616 for details
Authentication identity (authcid) to present for SASL/PLAIN or SASL/SCRAM authentication
Password for SASL/PLAIN authentication
Authz id used for SASL/SCRAM authentication
Enterprise only. Defines how to connect to a Kafka cluster
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
7 nested properties
Name of the enabled SASL mechanism
Kafka > 1.x should use SASL V1, except on Azure EventHub which uses V0
Whether or not to send the Kafka SASL handshake first if enabled. You should only set this to false if you're using a non-Kafka SASL proxy
Auth Identity is an (optional) authorization identity (authzid) to use for SASL/PLAIN authentication (if different from User) when an authenticated user is permitted to act as the presented alternative user. See RFC4616 for details
Authentication identity (authcid) to present for SASL/PLAIN or SASL/SCRAM authentication
Password for SASL/PLAIN authentication
Authz id used for SASL/SCRAM authentication
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.
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.
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.
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.
A name to give to the client stablishing the connection
A name to identify the rack we are connecting from
The number of events to buffer in internal and external channels. This permits the producer and consumer to continue processing some messages in the background while user code is working, greatly improving throughput
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.
When a disconnection happens, the client needs to refresh its metadata to know the current state of the kafka cluster (effectively the number of attempts to reconnect)
Enterprise only. Defines details about how to write messages to a Kafka cluster
Maximum permitted size of a message. Should be set equal to or smaller than the broker's message.max.bytes.
Level of acknowledgement reliability needed from the broker. Equivalent to the request.required.acks setting of the JVM producer. Can be a positibe number (as a string), or one of hte following values: no_response (no required acks), wait_for_local (waits for only the local commit to succeed before responding), wait_for_all (waits for all in-sync replicas to commit before responding).
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.
Type of compression to use on messages (defaults to no compression). Similar to compression.codec setting of the JVM producer.
Level of compression to use on messages. The meaning depends on the actual compression type used and defaults to default compression level for the codec.
Select behaviour for choosing the partition to send messages (similar to the partitioner.class setting for the JVM producer). The options are:
sarama: DEPRECATED uses a Partitioner which behaves as follows: If the message's key is nil then a random partition is chosen. Otherwise theFNV-1ahash of the encoded bytes of the message key is used, modulus the number of partitions. This ensures that messages with the same key always end up on the same partition.standardis likesaramaexcept that it handles absolute values in the same way as the reference Java implementation.saramawas supposed to do that but it had a mistake and now there are people depending on both behaviours. This will all go away on the next major version bump.randomuses a Partitioner which chooses a random partition each time.roundrobinuses a Partitioner which walks through the available partitions one at a time.
If enabled, the producer will ensure that exactly one copy of each message is written
The total number of times to retry sending a message. Similar to the message.send.max.retries setting of the JVM producer.
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.
Enterprise only. Defines how to write messages to a Kafka cluster
Enterprise only. Defines how to connect to a Kafka cluster
12 nested properties
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
7 nested properties
Name of the enabled SASL mechanism
Kafka > 1.x should use SASL V1, except on Azure EventHub which uses V0
Whether or not to send the Kafka SASL handshake first if enabled. You should only set this to false if you're using a non-Kafka SASL proxy
Auth Identity is an (optional) authorization identity (authzid) to use for SASL/PLAIN authentication (if different from User) when an authenticated user is permitted to act as the presented alternative user. See RFC4616 for details
Authentication identity (authcid) to present for SASL/PLAIN or SASL/SCRAM authentication
Password for SASL/PLAIN authentication
Authz id used for SASL/SCRAM authentication
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.
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.
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.
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.
A name to give to the client stablishing the connection
A name to identify the rack we are connecting from
The number of events to buffer in internal and external channels. This permits the producer and consumer to continue processing some messages in the background while user code is working, greatly improving throughput
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.
When a disconnection happens, the client needs to refresh its metadata to know the current state of the kafka cluster (effectively the number of attempts to reconnect)
Topic to write to
Enterprise only. Defines details about how to write messages to a Kafka cluster
9 nested properties
Maximum permitted size of a message. Should be set equal to or smaller than the broker's message.max.bytes.
Level of acknowledgement reliability needed from the broker. Equivalent to the request.required.acks setting of the JVM producer. Can be a positibe number (as a string), or one of hte following values: no_response (no required acks), wait_for_local (waits for only the local commit to succeed before responding), wait_for_all (waits for all in-sync replicas to commit before responding).
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.
Type of compression to use on messages (defaults to no compression). Similar to compression.codec setting of the JVM producer.
Level of compression to use on messages. The meaning depends on the actual compression type used and defaults to default compression level for the codec.
Select behaviour for choosing the partition to send messages (similar to the partitioner.class setting for the JVM producer). The options are:
sarama: DEPRECATED uses a Partitioner which behaves as follows: If the message's key is nil then a random partition is chosen. Otherwise theFNV-1ahash of the encoded bytes of the message key is used, modulus the number of partitions. This ensures that messages with the same key always end up on the same partition.standardis likesaramaexcept that it handles absolute values in the same way as the reference Java implementation.saramawas supposed to do that but it had a mistake and now there are people depending on both behaviours. This will all go away on the next major version bump.randomuses a Partitioner which chooses a random partition each time.roundrobinuses a Partitioner which walks through the available partitions one at a time.
If enabled, the producer will ensure that exactly one copy of each message is written
The total number of times to retry sending a message. Similar to the message.send.max.retries setting of the JVM producer.
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.
Name of the header where the kafka message key value is written
Enterprise only. Allows for fine grained control over a kafka publishing connection
Enterprise only. Defines how to write messages to a Kafka cluster
4 nested properties
Enterprise only. Defines how to connect to a Kafka cluster
12 nested properties
TLS options to connect to upstream services.
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
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.
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.
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.
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.
A name to give to the client stablishing the connection
A name to identify the rack we are connecting from
The number of events to buffer in internal and external channels. This permits the producer and consumer to continue processing some messages in the background while user code is working, greatly improving throughput
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.
When a disconnection happens, the client needs to refresh its metadata to know the current state of the kafka cluster (effectively the number of attempts to reconnect)
Topic to write to
Enterprise only. Defines details about how to write messages to a Kafka cluster
9 nested properties
Maximum permitted size of a message. Should be set equal to or smaller than the broker's message.max.bytes.
Level of acknowledgement reliability needed from the broker. Equivalent to the request.required.acks setting of the JVM producer. Can be a positibe number (as a string), or one of hte following values: no_response (no required acks), wait_for_local (waits for only the local commit to succeed before responding), wait_for_all (waits for all in-sync replicas to commit before responding).
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.
Type of compression to use on messages (defaults to no compression). Similar to compression.codec setting of the JVM producer.
Level of compression to use on messages. The meaning depends on the actual compression type used and defaults to default compression level for the codec.
Select behaviour for choosing the partition to send messages (similar to the partitioner.class setting for the JVM producer). The options are:
sarama: DEPRECATED uses a Partitioner which behaves as follows: If the message's key is nil then a random partition is chosen. Otherwise theFNV-1ahash of the encoded bytes of the message key is used, modulus the number of partitions. This ensures that messages with the same key always end up on the same partition.standardis likesaramaexcept that it handles absolute values in the same way as the reference Java implementation.saramawas supposed to do that but it had a mistake and now there are people depending on both behaviours. This will all go away on the next major version bump.randomuses a Partitioner which chooses a random partition each time.roundrobinuses a Partitioner which walks through the available partitions one at a time.
If enabled, the producer will ensure that exactly one copy of each message is written
The total number of times to retry sending a message. Similar to the message.send.max.retries setting of the JVM producer.
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.
Name of the header where the kafka message key value is written
HTTP status code to return for a successful write in the queue
Subscribes a backend using the desired driver.
Subscription URL according to the selected driver
Enterprise only. Defines the detaisl for a Kafka consumer group.
Name of the consumer group to use
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.
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.
Priority-ordered list of client-side consumer group balancing strategies that will be offered to the coordinator. The first strategy that all group members support will be chosen by the leader. Options are: range, roundrobin, and sticky
[
"range"
]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.
Support KIP-345
The default number of message bytes to fetch from the broker in each request (default 1MB). This should be larger than the majority of your messages, or else the consumer will spend a lot of time negotiating sizes and not actually consuming. Similar to the JVM's fetch.message.max.bytes
Supports 2 modes: read_commited to consume and return all messages in message channel, and read_uncommited to hide messages that are part of an aborted transaction
Enterprise only. Defines how to read messages from a Kafka cluster
Enterprise only. Defines how to connect to a Kafka cluster
12 nested properties
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
7 nested properties
Name of the enabled SASL mechanism
Kafka > 1.x should use SASL V1, except on Azure EventHub which uses V0
Whether or not to send the Kafka SASL handshake first if enabled. You should only set this to false if you're using a non-Kafka SASL proxy
Auth Identity is an (optional) authorization identity (authzid) to use for SASL/PLAIN authentication (if different from User) when an authenticated user is permitted to act as the presented alternative user. See RFC4616 for details
Authentication identity (authcid) to present for SASL/PLAIN or SASL/SCRAM authentication
Password for SASL/PLAIN authentication
Authz id used for SASL/SCRAM authentication
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.
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.
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.
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.
A name to give to the client stablishing the connection
A name to identify the rack we are connecting from
The number of events to buffer in internal and external channels. This permits the producer and consumer to continue processing some messages in the background while user code is working, greatly improving throughput
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.
When a disconnection happens, the client needs to refresh its metadata to know the current state of the kafka cluster (effectively the number of attempts to reconnect)
List of topics to read from
Enterprise only. Defines the detaisl for a Kafka consumer group.
8 nested properties
Name of the consumer group to use
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.
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.
Priority-ordered list of client-side consumer group balancing strategies that will be offered to the coordinator. The first strategy that all group members support will be chosen by the leader. Options are: range, roundrobin, and sticky
[
"range"
]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.
Support KIP-345
The default number of message bytes to fetch from the broker in each request (default 1MB). This should be larger than the majority of your messages, or else the consumer will spend a lot of time negotiating sizes and not actually consuming. Similar to the JVM's fetch.message.max.bytes
Supports 2 modes: read_commited to consume and return all messages in message channel, and read_uncommited to hide messages that are part of an aborted transaction
Name of the header where the kafka message key value is written
Enterprise only. Allows for fine grained control over a kafka subcription connection
Enterprise only. Defines how to read messages from a Kafka cluster
4 nested properties
Enterprise only. Defines how to connect to a Kafka cluster
12 nested properties
TLS options to connect to upstream services.
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
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.
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.
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.
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.
A name to give to the client stablishing the connection
A name to identify the rack we are connecting from
The number of events to buffer in internal and external channels. This permits the producer and consumer to continue processing some messages in the background while user code is working, greatly improving throughput
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.
When a disconnection happens, the client needs to refresh its metadata to know the current state of the kafka cluster (effectively the number of attempts to reconnect)
List of topics to read from
Enterprise only. Defines the detaisl for a Kafka consumer group.
8 nested properties
Name of the consumer group to use
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.
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.
Priority-ordered list of client-side consumer group balancing strategies that will be offered to the coordinator. The first strategy that all group members support will be chosen by the leader. Options are: range, roundrobin, and sticky
[
"range"
]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.
Support KIP-345
The default number of message bytes to fetch from the broker in each request (default 1MB). This should be larger than the majority of your messages, or else the consumer will spend a lot of time negotiating sizes and not actually consuming. Similar to the JVM's fetch.message.max.bytes
Supports 2 modes: read_commited to consume and return all messages in message channel, and read_uncommited to hide messages that are part of an aborted transaction
Name of the header where the kafka message key value is written
Enterprise only. Build and modify requests to communicate with SOAP services.
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.
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.
The path to the Go template file you want to use to craft the body.
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.
Enterprise only. Allows you to fetch and serve static content from the disk instead of a remote server, and you can use it to mock data.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Whether to allow directory listings or not
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. Crafts the body/payload using a templating system.
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/
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/
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/
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/
Enterprise only. 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/
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
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.
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).
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.
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()).
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()).
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.
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.
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
3 nested properties
The body you want to set, formatted in base64.
Scopes in which this modifier acts
The content-type representing the body you are setting
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
5 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
The name of the Cookie you want to check. Notice that the input_headers must contain Cookie in the list when you want to check cookies sent by the client.
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
If besides the cookie name, you set this value, it ensures the cookie has a literal match.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
9 nested properties
Name of the Cookie you want to set
Scopes in which this modifier acts
Value of the Cookie you want to set
Domain of the Cookie you want to set
Date in RFC 3339 format and is absolute, not relative to the current time.
Create the Cookie with the httpOnly flag. When true, mitigates the risk of client side script accessing the protected cookie (if the browser supports it), mitigating the Most Common XSS
For how long this Cookie is valid, in seconds. 0 means that the attribute is not set. maxAge<0 means delete cookie now
Path of the Cookie you want to set
Cookie secure flag. When true, the user agent will include the cookie in the request when using https only
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
3 nested properties
The list of modifiers you want to execute in the declared order
Scopes in which this modifier acts
When true, the group will continue to execute consecutive modifiers when a modifier in the group encounters an error. The Group will then return all errors returned by each modifier after all modifiers have been executed. When false, if an error is returned by a modifier, the error is returned by ModifyRequest/Response and no further modifiers are run.
3 nested properties
Name of the header you want to append a value. Add the same name under the input_headers list to append more values to an existing header passed by the client. In addition, to see the header in the response, you must use no-op.
Scopes in which this modifier acts
The value you want to add or append.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
2 nested properties
List of all the headers you want to supress from the request or the response. If you want to see the headers in the client, you must use the output_encoding: no-op, and if you want the client headers to propagate to the backend, you need to use input_headers too.
Scopes in which this modifier acts
The header.Copy lets you duplicate a header using another name
3 nested properties
The origin header you want to copy. When the header is provided by the user it must be included in the input_headers list.
Scopes in which this modifier acts
The destination header you want to create. If this header is returned to the end-user you must use no-op in the output_encoding of the endpoint.
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
5 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
Name of the header you want to check. You must add under input_headers the name included in the filter.
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
Value of the header you want to check
2 nested properties
Scopes in which this modifier acts
The header name you want to use to save the ID. In the case the header is already set, the header is unmodified.
The header.Modifier adds a new header or changes the value of an existing one.
3 nested properties
Name of the header you want to set
Scopes in which this modifier acts
Value of the header you want to set
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
4 nested properties
Name of the header you want to check. You must add under input_headers the name included in the filter.
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
The regular expression you want to check against the header value
Scopes in which this modifier acts
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
4 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
The port number you want to check
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
The port.Modifier alters the request URL and Host header to use the provided port.
4 nested properties
Uses the default port of the schema. 80 for <http://> or 443 for <https://>. Other schemas are ignored.
Defines which port will be used.
Removes the port from the host string when true.
Scopes in which this modifier acts
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
2 nested properties
The list of modifiers you want to execute, order specified in the items using priority.
Scopes in which this modifier acts
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
5 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
Name of the query string you want to check
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
Value of the query string you want to check
The querystring.Modifier adds a new query string or modifies existing ones in the request.
3 nested properties
Name of the query string you want to set
Scopes in which this modifier acts
The value of the query string you want to set
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
2 nested properties
The header you want to create. If this header is returned to the end-user you must use no-op in the output_encoding of the endpoint.
Scopes in which this modifier acts
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
7 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
The literal hostname that must match, including the port
The /path of the URL, without query strings.
The query strings you want to check. Use key1=value1&key2=value2 to check that the request has exactly these keys and values (order is irrelevant, but content not). Suppose the request has more query strings than declared here because the input_query_strings allowed them to pass. In that case, the evaluation will be false, and the else modifier will be executed.
The literal scheme it must match
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
5 nested properties
Scopes in which this modifier acts
The hostname part of the URL including the port
The path part of the URL
Sets the query string parameters you want to pass, overwriting anything passed in the request. Notice that if you set a query, if the user passes other query string parameters listed under input_query_strings, they will be lost, and only the values passed in the modifier will be sent. For such uses, see the querystring.Modifier
The scheme to apply
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
4 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
The regular expression you want to check against the URL
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
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: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
A list of modifiers you would like to apply to specific fields. The modifiers are evaluated and applied in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
[]The name of the plugin to load. Only one plugin is supported per backend.
See: https://www.krakend.io/docs/extending/injecting-plugins/
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/enterprise/extending/middleware-plugins/
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/
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/
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
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/
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
2 nested properties
The error message you want to show when the validation fails. Set it to an empty string "" to show the JSON-schema validation error.
The HTTP status code you want to set back in the response.
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/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
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/
[]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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
2 nested properties
The error message you want to show when the validation fails. Set it to an empty string "" to show the JSON-schema validation error.
The HTTP status code you want to set back in the response.
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.
[ { "type": "move", "args": [ "a.*.b1.*.c", "a.*.b1.*.d" ] } ]
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.
Mark this backend as a shadow backend. Sending copies of the traffic but ignore its responses.
The circuit breaker prevents sending more traffic to a failing backend.
Time window where the errors count, in seconds.
The CONSECUTIVE (not total) number of errors within the interval window to consider the backend unhealthy. All HTTP status codes different than 20x are considered an error, except for the no-op encoding that does not evaluate status codes and is limited to connectivity/networking, security and component errors. See the definition of error below.
For how many seconds the circuit breaker will wait before testing again if the backend is healthy.
Whether to log the changes of state of this circuit breaker or not.
A friendly name to follow this circuit breaker's activity in the logs.
Enterprise only. The HTTP circuit breaker prevents sending more traffic to a backend that is returning status codes that are considered errors.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Time window where the errors count, in seconds.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
The CONSECUTIVE (not total) number of errors within the interval window to consider the backend unhealthy. All HTTP status codes different than 20x are considered an error, except for the no-op encoding that does not evaluate status codes and is limited to connectivity/networking, security and component errors. See the definition of error below.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
For how many seconds the circuit breaker will wait before testing again if the backend is healthy. This number of seconds can also be read as the minimum cooldown of the backend interaction.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
A list of HTTP status codes that will be considered successful responses. Any response with a status code not in this list will be counted as an error by the circuit breaker.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Whether to log the changes of state of this circuit breaker or not.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
A friendly name to follow this circuit breaker's activity in the logs.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Restrict the rate of requests KrakenD makes to your backends.
The capacity according to the token bucket algorithm. Defines the maximum requests you can do in an instant (including the zero moment when you start the gateway), and can be larger or smaller than the max_rate. When unsure, use the same value of max_rate, so the maximum number of requests can be consumed at once.
Maximum requests per second you want to accept in this backend.
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.
Enables the Backend Log capabilities.
Specify the custom format of the Backend Logs.
What type of reporting level do you want to set at the backends? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
When the variable does not resolve to any value, the string you want to write in the log. If the string is set to an empty value, a dash - is printed.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on.
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
2 nested properties
5 nested properties
Whether you want to enable detailed metrics for the HTTP connection phase or not. Includes times to connect, DNS querying, and the TLS handshake.
Whether to turn off the metrics or not. Setting this to true means stop reporting any data.
Whether you want to enable metrics for the response reading payload or not (HTTP connection not taken into account).
Whether you want to enable metrics for the actual HTTP request for the backend or not (manipulation not taken into account). This is the time your backend needs to produce a result.
a list of tags or labels you want to associate with these metrics.
7 nested properties
Whether you want to add detailed trace attributes for the HTTP connection phase or not. Includes times to connect, DNS querying, and the TLS handshake.
Whether to turn off the traces or not. Setting this to true means stop reporting any data.
Whether you want to add trace attributes for the response reading payload or not (HTTP connection not taken into account).
Whether you want to report the final headers that reached the backend.
Whether you want to add trace attributes for the actual HTTP request for the backend or not (manipulation not taken into account). This is the time your backend needs to produce a result.
A list of headers you want to skip when reporting the headers that reached the backend. This is useful to avoid reporting sensitive data.
a list of tags or labels you want to associate with these metrics.
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/
Enterprise only. The response schema validator 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/
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
3 nested properties
The error message you want to show when the validation fails. Set it to an empty string "" to show the JSON-schema validation error.
The Content-Type header you want to set back in the response when you are setting a custom body
The HTTP status code you want to set back in the response.
Enterprise only. 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/
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
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/
1 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
3 nested properties
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/
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/
The HTTP status code you want to return when the validation fails.
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
3 nested properties
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/
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/
The HTTP status code you want to return when the validation fails.
See: https://www.krakend.io/docs/enterprise/security-policies/
Enterprise only. 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/
1 nested properties
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
4 nested properties
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/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
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/
[]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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
5 nested properties
For custom builds of KrakenD only
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.
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/
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/
The static proxy injects static data in the final response when the selected strategy matches.
2 nested properties
The static data (as a JSON object) that you will return.
One of the supported strategies
Enterprise only. 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/
6 nested properties
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
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/
1 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
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/
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.
List of all the backend objects called within this workflow. Each backend can initiate another workflow if needed.
An endpoint name for the workflow that will be used in logs. The name will be appended to the string /__workflow/ in the logs, and although it does not receive traffic under this route, it is necessary when you want to pass URL {params} to the nested backends.
The concurrent requests are an excellent technique to improve the response times and decrease error rates by requesting in parallel the same information multiple times. Yes, you make the same request to several backends instead of asking to just one. When the first backend returns the information, the remaining requests are canceled.
See: https://www.krakend.io/docs/endpoints/concurrent-requests/
9 nested properties
Enterprise only. 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/
1 nested properties
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
4 nested properties
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/
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/
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/
[]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/
5 nested properties
For custom builds of KrakenD only
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.
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/
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/
The static proxy injects static data in the final response when the selected strategy matches.
Enterprise only. 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/
6 nested properties
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
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/
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
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/
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.
Allow the workflow to continue with the rest of declared actions when there are errors (like security policies, network errors, etc). The default behavior of KrakenD is to abort an execution that has errors as soon as possible. If you use conditional backends and similar approaches, you might want to allow the gateway to go through all steps.
The gateway can work with several content types, even allowing your clients to choose how to consume the content. See the supported encodings
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.
Ready-to-use LLM connectors available for major AI vendors.
See: https://www.krakend.io/docs/enterprise/ai-gateway/unified-llm-interface/
5 nested properties
Connect to Anthropic models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Connect to Google Gemini models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Connect to Mistral models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
Connect to OpenAI's GPT models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
Connect to Bedrock models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
1 nested properties
All settings depend on a specific version, as the vendor might change the API over time.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Enterprise only. Enables AWS Sigv4 authentication between KrakenD and Google Cloud service account.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
5 nested properties
The AWS region where the service is deployed.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The name of the service in AWS you'd like to sign the request.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The Amazon Resource Name (ARN) of the role to assume.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
Enables debug logging for AWS Sigv4 signing process.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The AWS region where the STS service is deployed.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
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/
5 nested properties
The Client ID provided to the Auth server
See: https://www.krakend.io/docs/authorization/client-credentials/
The secret string provided to the Auth server.
See: https://www.krakend.io/docs/authorization/client-credentials/
The endpoint URL where the negotiation of the token happens
See: https://www.krakend.io/docs/authorization/client-credentials/
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/
A comma-separated list of scopes needed, e.g.: scopeA,scopeB
See: https://www.krakend.io/docs/authorization/client-credentials/
Enterprise only. Enables GCP authentication between KrakenD and Google Cloud service account.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
5 nested properties
The audience in GCP looks like an URL, and contains the destination service you will ask a token for. Most of the times this URL will match exactly with the host entry.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The relative or absolute path to a credentials file in JSON format that contains all the credentials to authenticate API calls to the given service account.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
An inline JSON object containing all the credentials fields to authenticate to GCP.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
Custom private claims that you can optionally add to an ID token.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The header name to use in service-to-service authentication. This is useful to honor the original Authorization header in case it's needed by the backend (for example, CloudRun).
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
Enterprise only. Enables NTLM authentication between KrakenD and a Microsoft server such as Dynamics.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
2 nested properties
The password you will use, in clear text.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The username you will send as NTLM authentication user.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The AMQP component allows to send and receive messages to and from a queue through the API Gateway.
13 nested properties
The exchange name (must have a topic type if already exists).
Queue name.
The list of routing keys you will use to consume messages.
When KrakenD retrieves the messages, regardless of the success or failure of the operation, it marks them as ACKnowledge.
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. Check the meaning of each strategy.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
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.
When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries.
When true, messages that cannot be processed are discarded instead of being sent back to the queue. This is useful for scenarios where you want to avoid reprocessing failed messages.
The no_local flag is not supported by RabbitMQ.
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.
The number of messages you want to prefetch prior to consume them.
Send messages to a queue through the API Gateway.
17 nested properties
The exchange name (must have a topic type if already exists).
Queue name.
The routing key you will use to send messages, case sensitive.
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. Check the meaning of each strategy.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
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.
When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
Take a parameter from a {placeholder} in the endpoint definition to use as the expiration key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
A consumer must be connected to the queue when true.
The exchange must have at least one queue bound when true.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries.
Take a parameter from a {placeholder} in the endpoint definition to use as the message identifier. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
The no_local flag is not supported by RabbitMQ.
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.
Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
Defines whether the routing_key will have a static value or not, instead of taking the value from a parameter.
Evaluates a rule to determine if the backend is callable or not, and skip to the next one in case it's not.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
3 nested properties
Choose header when you want to check the value of a specific header, policy when you want to write a more complex logical expression, or fallback when the backend will execute when all the rest of conditional backends have failed to evaluate to true. Only one fallback can be defined per endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Only used with the header strategy. It is the name of the header you want to use for the evaluation in the canonical format of the MIME header. Make sure to declare the header in the input_headers list of the endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
The value according to the strategy. With the header strategy, this is the literal value contained in the header (case sensitive). With the policy strategy, the Security Policy expression. When using policies you can access to the variables req and req_params (a previous backend response might be in the latter), and to advanced macros. Access to headers require you to add the corresponding input_headers in the endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Convert REST endpoints to GraphQL calls (adapter/transformer)
5 nested properties
The type of query you are declaring, query (read), or mutation (write).
A meaningful and explicit name for your operation, required in multi-operation documents and for helpful debugging and server-side logging.
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.
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.
A dictionary defining all the variables sent to the GraphQL server. You can use {placeholders} to inject parameters from the endpoint URL.
Enterprise only. Handles the communication with a backend using gRPC, after having defined the protocol buffer definitions.
16 nested properties
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
When true, it does not use URL parameters ({placeholders} in endpoints) or query strings to fill the gRPC payload to send. If use_request_body is not set, or set to false, and this option is set to true, there will be no input used for the gRPC message to send. That is still a valid option, when we just want to send the message with its default values, or when the input for the gRPC calls is just the empty message.
A dictionary that rename the received header (key) to a new header name (value). If the header starts with grpc they will be renamed to in-grpc-* as the word is reserved.
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.
When set to true, when the backend has to fill a bytes field for a grpc protobuf payload to send, first tries to decode the input data (the one coming from either a json body field, a query param or header string) from base64: if it succeeds it fills the field to send with that binary / bytes data. If the incoming field is not a valid base64 decoded field (the one used in jsonpb), it will fill the binary field with the verbatim conversion of the incoming string to bytes.
A dictionary that converts query string parameters and parameters from {placeholders} into a different field during the backend request. When passing parameters using {placeholder} the parameter capitalizes the first letter, so you receive Placeholder.
Specifies the maximum size (in bytes) for messages the grpc client is allowed to receive. If the value is unset, or 0, it uses its default (4MB)
Well-known Duration types (google.protobuf.Duration) are returned as a struct containing fields with seconds and nanos fields (flag set to false). Setting this flag to true transforms the timestamps into a string representation in seconds.
Enum types are returned as numeric values (flag set to false). Set this flag to true to return the string representation of the enum value. For instance, an enum representing allergies, such as ['NUTS', 'MILK', ' SOY', 'WHEAT'] would return a value SOY when this flag is true, or 2 when false.
This attribute defines what to do when a field that is declared in the definition does not exist in the backend response. When the flag is true, any fields in the definition that are not present in the backend response are removed before returning the content to the user. When the flag is false missing fields are returned but set with a zeroed-value depending on its type (zero, nil, false, etc).
Well-known Timestamp types (google.protobuf.Timestamp) are returned as a struct containing fields with seconds and nanos fields (flag set to false). Setting this flag to true transforms the timestamps into a string representation in RFC3999 format.
Specifies the size of the client buffer reading the gRPC communication in bytes. If the value is unset, or 0, it uses its default (32KB). Use a negative value to disable the buffer, and if you do there won't be memory pre-allocation to read. To determine the right number, calculate the average size of the responses the gRPC client will receive.
Defines the naming convention used to format the request. Applies to query strings and JSON field names. By default, the gateway uses snake_case which makes use of the standard encoding/json package, while when you choose camelCase the protobuf/encoding deserialization is used instead.
Defines the naming convention used to format the returned data. By default, the gateway uses snake_case which makes use of the standard encoding/json package, while when you choose camelCase the protobuf/encoding deserialization is used instead.
When true, before sending a message to a host, it checks if the connection status is in a "transient failure" or "failure" state and tries to use a different host (from the service discovery or randomly from the list of hosts). If the connection is in a valid state, but an error happens when sending the gRPC message, it also tries to use a different host to retry sending the message. Depending on the host list, the retry attempts may go to the same host initially in a "bad state".
Enables the use of the sent body to fill the gRPC request. Take into account that when you set this flag to true a body is expected, and this body is consumed in the first backend. If the endpoint that uses this gRPC backend has additional backends (either gRPC or HTTP) that also expect to consume the payload, these requests might fail.
2 nested properties
Returns the HTTP status code of the backend (when there is only one). The headers are not returned.
Returns to the client details of a failing request.
Enterprise only. Allows you to set the different HTTP client options with the backend, like TLS, no redirect or connect via a proxy.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
4 nested properties
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Set no_redirect to true if you don't want KrakenD to follow redirects and let the consuming user to receive the 30x status code.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
The proxy address used to forward the traffic. The address must contain the protocol and the port.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
Post the original body to the final URL after a 307 or a 308 redirection.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
Invoke Amazon Lambda functions on a KrakenD endpoint call.
5 nested properties
An optional parameter to customize the Lambda endpoint to call. Useful when Localstack is used for testing instead of direct AWS usage.
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.
The endpoint {placeholder} that sets the function name, with the first letter uppercased. You have to choose between function_name and function_param_name but not both. If your endpoint defines the route /foo/{bar} the value of function_param_name must be Bar with the uppercased B.
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.
The AWS identifier region
Publishes to a topic using the desired driver.
1 nested properties
Topic URL according to the selected driver
Subscribes a backend using the desired driver.
1 nested properties
Subscription URL according to the selected driver
Enterprise only. Allows for fine grained control over a kafka publishing connection
2 nested properties
Enterprise only. Defines how to write messages to a Kafka cluster
4 nested properties
HTTP status code to return for a successful write in the queue
Enterprise only. Allows for fine grained control over a kafka subcription connection
1 nested properties
Enterprise only. Defines how to read messages from a Kafka cluster
4 nested properties
Enterprise only. Build and modify requests to communicate with SOAP services.
4 nested properties
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.
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.
The path to the Go template file you want to use to craft the body.
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.
Enterprise only. Allows you to fetch and serve static content from the disk instead of a remote server, and you can use it to mock data.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
2 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Whether to allow directory listings or not
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
7 nested properties
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
Enterprise only. 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/
1 nested properties
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
3 nested properties
The body you want to set, formatted in base64.
Scopes in which this modifier acts
The content-type representing the body you are setting
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
5 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The name of the Cookie you want to check. Notice that the input_headers must contain Cookie in the list when you want to check cookies sent by the client.
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
If besides the cookie name, you set this value, it ensures the cookie has a literal match.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
9 nested properties
Name of the Cookie you want to set
Scopes in which this modifier acts
Value of the Cookie you want to set
Domain of the Cookie you want to set
Date in RFC 3339 format and is absolute, not relative to the current time.
Create the Cookie with the httpOnly flag. When true, mitigates the risk of client side script accessing the protected cookie (if the browser supports it), mitigating the Most Common XSS
For how long this Cookie is valid, in seconds. 0 means that the attribute is not set. maxAge<0 means delete cookie now
Path of the Cookie you want to set
Cookie secure flag. When true, the user agent will include the cookie in the request when using https only
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
3 nested properties
The list of modifiers you want to execute in the declared order
Scopes in which this modifier acts
When true, the group will continue to execute consecutive modifiers when a modifier in the group encounters an error. The Group will then return all errors returned by each modifier after all modifiers have been executed. When false, if an error is returned by a modifier, the error is returned by ModifyRequest/Response and no further modifiers are run.
3 nested properties
Name of the header you want to append a value. Add the same name under the input_headers list to append more values to an existing header passed by the client. In addition, to see the header in the response, you must use no-op.
Scopes in which this modifier acts
The value you want to add or append.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
2 nested properties
List of all the headers you want to supress from the request or the response. If you want to see the headers in the client, you must use the output_encoding: no-op, and if you want the client headers to propagate to the backend, you need to use input_headers too.
Scopes in which this modifier acts
The header.Copy lets you duplicate a header using another name
3 nested properties
The origin header you want to copy. When the header is provided by the user it must be included in the input_headers list.
Scopes in which this modifier acts
The destination header you want to create. If this header is returned to the end-user you must use no-op in the output_encoding of the endpoint.
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
5 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
Name of the header you want to check. You must add under input_headers the name included in the filter.
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
Value of the header you want to check
2 nested properties
Scopes in which this modifier acts
The header name you want to use to save the ID. In the case the header is already set, the header is unmodified.
The header.Modifier adds a new header or changes the value of an existing one.
3 nested properties
Name of the header you want to set
Scopes in which this modifier acts
Value of the header you want to set
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
4 nested properties
Name of the header you want to check. You must add under input_headers the name included in the filter.
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The regular expression you want to check against the header value
Scopes in which this modifier acts
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
4 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The port number you want to check
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The port.Modifier alters the request URL and Host header to use the provided port.
4 nested properties
Uses the default port of the schema. 80 for <http://> or 443 for <https://>. Other schemas are ignored.
Defines which port will be used.
Removes the port from the host string when true.
Scopes in which this modifier acts
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
2 nested properties
The list of modifiers you want to execute, order specified in the items using priority.
Scopes in which this modifier acts
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
5 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
Name of the query string you want to check
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
Value of the query string you want to check
The querystring.Modifier adds a new query string or modifies existing ones in the request.
3 nested properties
Name of the query string you want to set
Scopes in which this modifier acts
The value of the query string you want to set
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
2 nested properties
The header you want to create. If this header is returned to the end-user you must use no-op in the output_encoding of the endpoint.
Scopes in which this modifier acts
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
7 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The literal hostname that must match, including the port
The /path of the URL, without query strings.
The query strings you want to check. Use key1=value1&key2=value2 to check that the request has exactly these keys and values (order is irrelevant, but content not). Suppose the request has more query strings than declared here because the input_query_strings allowed them to pass. In that case, the evaluation will be false, and the else modifier will be executed.
The literal scheme it must match
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
5 nested properties
Scopes in which this modifier acts
The hostname part of the URL including the port
The path part of the URL
Sets the query string parameters you want to pass, overwriting anything passed in the request. Notice that if you set a query, if the user passes other query string parameters listed under input_query_strings, they will be lost, and only the values passed in the modifier will be sent. For such uses, see the querystring.Modifier
The scheme to apply
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
4 nested properties
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
The regular expression you want to check against the URL
Scopes in which this modifier acts
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
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: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
1 nested properties
A list of modifiers you would like to apply to specific fields. The modifiers are evaluated and applied in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
[]Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
1 nested properties
The name of the plugin to load. Only one plugin is supported per backend.
See: https://www.krakend.io/docs/extending/injecting-plugins/
1 nested properties
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/enterprise/extending/middleware-plugins/
4 nested properties
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/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
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/
[]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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
2 nested properties
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.
Mark this backend as a shadow backend. Sending copies of the traffic but ignore its responses.
The circuit breaker prevents sending more traffic to a failing backend.
5 nested properties
Time window where the errors count, in seconds.
The CONSECUTIVE (not total) number of errors within the interval window to consider the backend unhealthy. All HTTP status codes different than 20x are considered an error, except for the no-op encoding that does not evaluate status codes and is limited to connectivity/networking, security and component errors. See the definition of error below.
For how many seconds the circuit breaker will wait before testing again if the backend is healthy.
Whether to log the changes of state of this circuit breaker or not.
A friendly name to follow this circuit breaker's activity in the logs.
Enterprise only. The HTTP circuit breaker prevents sending more traffic to a backend that is returning status codes that are considered errors.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
6 nested properties
Time window where the errors count, in seconds.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
The CONSECUTIVE (not total) number of errors within the interval window to consider the backend unhealthy. All HTTP status codes different than 20x are considered an error, except for the no-op encoding that does not evaluate status codes and is limited to connectivity/networking, security and component errors. See the definition of error below.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
For how many seconds the circuit breaker will wait before testing again if the backend is healthy. This number of seconds can also be read as the minimum cooldown of the backend interaction.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
A list of HTTP status codes that will be considered successful responses. Any response with a status code not in this list will be counted as an error by the circuit breaker.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Whether to log the changes of state of this circuit breaker or not.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
A friendly name to follow this circuit breaker's activity in the logs.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Enable in-memory caching for backend responses for as long as its Cache-Control header permits. Only safe methods are cached (GET or HEAD). The final backend URL and the Vary headers are used to create the caching key.
3 nested properties
To be released on open source on v2.10. The maximum number of items the LRU cache will store for this cache bucket before starting to do evictions. When max_items is declared, you must declare max_size as well.
To be released on open source on v2.10. The maximum number of bytes you allow the LRU cache to store for this cache bucket before starting to do evictions. This is not the total cache you allow to the system, but the number of bytes you reserve to this backend (or its shared neighbours). will store before starting to do evictions. When max_size is declared, you must declare max_items as well.
Allows different backend definitions with this flag set to true to reuse the store between them when the request is the same. Otherwise, each backend uses a private cache context that is not accessible by other endpoints. The cache definition is unique for every backend URL + Vary header combination.
Restrict the rate of requests KrakenD makes to your backends.
3 nested properties
The capacity according to the token bucket algorithm. Defines the maximum requests you can do in an instant (including the zero moment when you start the gateway), and can be larger or smaller than the max_rate. When unsure, use the same value of max_rate, so the maximum number of requests can be consumed at once.
Maximum requests per second you want to accept in this backend.
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.
Enterprise only. 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/
5 nested properties
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
Enterprise only. Add a specific Backend Log. Useful to see status codes, headers, and other information that come from your backends.
1 nested properties
Enables the Backend Log capabilities.
4 nested properties
Specify the custom format of the Backend Logs.
What type of reporting level do you want to set at the backends? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
When the variable does not resolve to any value, the string you want to write in the log. If the string is set to an empty value, a dash - is printed.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on.
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
1 nested properties
Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
2 nested properties
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/
Enterprise only. The response schema validator 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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
3 nested properties
The error message you want to show when the validation fails. Set it to an empty string "" to show the JSON-schema validation error.
The Content-Type header you want to set back in the response when you are setting a custom body
The HTTP status code you want to set back in the response.
7 nested properties
List of all the backend objects called within this workflow. Each backend can initiate another workflow if needed.
An endpoint name for the workflow that will be used in logs. The name will be appended to the string /__workflow/ in the logs, and although it does not receive traffic under this route, it is necessary when you want to pass URL {params} to the nested backends.
The concurrent requests are an excellent technique to improve the response times and decrease error rates by requesting in parallel the same information multiple times. Yes, you make the same request to several backends instead of asking to just one. When the first backend returns the information, the remaining requests are canceled.
See: https://www.krakend.io/docs/endpoints/concurrent-requests/
9 nested properties
Enterprise only. 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/
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.
Enterprise only. Crafts the body/payload using a templating system.
Enterprise only. Crafts the body/payload using a templating system.
Enterprise only. 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/
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/
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.
Allow the workflow to continue with the rest of declared actions when there are errors (like security policies, network errors, etc). The default behavior of KrakenD is to abort an execution that has errors as soon as possible. If you use conditional backends and similar approaches, you might want to allow the gateway to go through all steps.
The gateway can work with several content types, even allowing your clients to choose how to consume the content. See the supported encodings
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.
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.
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.
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 returns {"a":{"b": true}}
See: https://www.krakend.io/docs/backends/data-manipulation/
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 define nested attributes, e.g.: a.b removes {"a":{"b": true}}.
See: https://www.krakend.io/docs/backends/data-manipulation/
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.
Defines your needed encoding to set how to parse the response. Defaults to the value of its endpoint's encoding, or to json if not defined anywhere else. Notice that fast-json and yaml are for Enterprise only.
See: https://www.krakend.io/docs/backends/supported-encodings/
41 nested properties
Ready-to-use LLM connectors available for major AI vendors.
See: https://www.krakend.io/docs/enterprise/ai-gateway/unified-llm-interface/
5 nested properties
Connect to Anthropic models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/anthropic/
Connect to Google Gemini models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/gemini/
Connect to Mistral models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mistral/
Connect to OpenAI's GPT models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/openai/
Connect to Bedrock models easily by providing your API key and optional parameters.
See: https://www.krakend.io/docs/enterprise/ai-gateway/bedrock/
Enterprise only. Enables AWS Sigv4 authentication between KrakenD and Google Cloud service account.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
5 nested properties
The AWS region where the service is deployed.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The name of the service in AWS you'd like to sign the request.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The Amazon Resource Name (ARN) of the role to assume.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
Enables debug logging for AWS Sigv4 signing process.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
The AWS region where the STS service is deployed.
See: https://www.krakend.io/docs/enterprise/authentication/aws-sigv4/
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/
5 nested properties
The Client ID provided to the Auth server
See: https://www.krakend.io/docs/authorization/client-credentials/
The secret string provided to the Auth server.
See: https://www.krakend.io/docs/authorization/client-credentials/
The endpoint URL where the negotiation of the token happens
See: https://www.krakend.io/docs/authorization/client-credentials/
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/
A comma-separated list of scopes needed, e.g.: scopeA,scopeB
See: https://www.krakend.io/docs/authorization/client-credentials/
Enterprise only. Enables GCP authentication between KrakenD and Google Cloud service account.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
5 nested properties
The audience in GCP looks like an URL, and contains the destination service you will ask a token for. Most of the times this URL will match exactly with the host entry.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The relative or absolute path to a credentials file in JSON format that contains all the credentials to authenticate API calls to the given service account.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
An inline JSON object containing all the credentials fields to authenticate to GCP.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
Custom private claims that you can optionally add to an ID token.
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
The header name to use in service-to-service authentication. This is useful to honor the original Authorization header in case it's needed by the backend (for example, CloudRun).
See: https://www.krakend.io/docs/enterprise/authentication/gcp/
Enterprise only. Enables NTLM authentication between KrakenD and a Microsoft server such as Dynamics.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
2 nested properties
The password you will use, in clear text.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The username you will send as NTLM authentication user.
See: https://www.krakend.io/docs/enterprise/authentication/ntlm/
The AMQP component allows to send and receive messages to and from a queue through the API Gateway.
13 nested properties
The exchange name (must have a topic type if already exists).
Queue name.
The list of routing keys you will use to consume messages.
When KrakenD retrieves the messages, regardless of the success or failure of the operation, it marks them as ACKnowledge.
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. Check the meaning of each strategy.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
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.
When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries.
When true, messages that cannot be processed are discarded instead of being sent back to the queue. This is useful for scenarios where you want to avoid reprocessing failed messages.
The no_local flag is not supported by RabbitMQ.
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.
The number of messages you want to prefetch prior to consume them.
Send messages to a queue through the API Gateway.
17 nested properties
The exchange name (must have a topic type if already exists).
Queue name.
The routing key you will use to send messages, case sensitive.
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. Check the meaning of each strategy.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
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.
When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
Take a parameter from a {placeholder} in the endpoint definition to use as the expiration key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
A consumer must be connected to the queue when true.
The exchange must have at least one queue bound when true.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries.
Take a parameter from a {placeholder} in the endpoint definition to use as the message identifier. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
The no_local flag is not supported by RabbitMQ.
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.
Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.
Defines whether the routing_key will have a static value or not, instead of taking the value from a parameter.
Evaluates a rule to determine if the backend is callable or not, and skip to the next one in case it's not.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
3 nested properties
Choose header when you want to check the value of a specific header, policy when you want to write a more complex logical expression, or fallback when the backend will execute when all the rest of conditional backends have failed to evaluate to true. Only one fallback can be defined per endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Only used with the header strategy. It is the name of the header you want to use for the evaluation in the canonical format of the MIME header. Make sure to declare the header in the input_headers list of the endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
The value according to the strategy. With the header strategy, this is the literal value contained in the header (case sensitive). With the policy strategy, the Security Policy expression. When using policies you can access to the variables req and req_params (a previous backend response might be in the latter), and to advanced macros. Access to headers require you to add the corresponding input_headers in the endpoint.
See: https://www.krakend.io/docs/enterprise/backends/conditional/
Convert REST endpoints to GraphQL calls (adapter/transformer)
5 nested properties
The type of query you are declaring, query (read), or mutation (write).
A meaningful and explicit name for your operation, required in multi-operation documents and for helpful debugging and server-side logging.
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.
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.
A dictionary defining all the variables sent to the GraphQL server. You can use {placeholders} to inject parameters from the endpoint URL.
Enterprise only. Handles the communication with a backend using gRPC, after having defined the protocol buffer definitions.
16 nested properties
TLS options to connect to upstream services.
When true, it does not use URL parameters ({placeholders} in endpoints) or query strings to fill the gRPC payload to send. If use_request_body is not set, or set to false, and this option is set to true, there will be no input used for the gRPC message to send. That is still a valid option, when we just want to send the message with its default values, or when the input for the gRPC calls is just the empty message.
A dictionary that rename the received header (key) to a new header name (value). If the header starts with grpc they will be renamed to in-grpc-* as the word is reserved.
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.
When set to true, when the backend has to fill a bytes field for a grpc protobuf payload to send, first tries to decode the input data (the one coming from either a json body field, a query param or header string) from base64: if it succeeds it fills the field to send with that binary / bytes data. If the incoming field is not a valid base64 decoded field (the one used in jsonpb), it will fill the binary field with the verbatim conversion of the incoming string to bytes.
A dictionary that converts query string parameters and parameters from {placeholders} into a different field during the backend request. When passing parameters using {placeholder} the parameter capitalizes the first letter, so you receive Placeholder.
Specifies the maximum size (in bytes) for messages the grpc client is allowed to receive. If the value is unset, or 0, it uses its default (4MB)
Well-known Duration types (google.protobuf.Duration) are returned as a struct containing fields with seconds and nanos fields (flag set to false). Setting this flag to true transforms the timestamps into a string representation in seconds.
Enum types are returned as numeric values (flag set to false). Set this flag to true to return the string representation of the enum value. For instance, an enum representing allergies, such as ['NUTS', 'MILK', ' SOY', 'WHEAT'] would return a value SOY when this flag is true, or 2 when false.
This attribute defines what to do when a field that is declared in the definition does not exist in the backend response. When the flag is true, any fields in the definition that are not present in the backend response are removed before returning the content to the user. When the flag is false missing fields are returned but set with a zeroed-value depending on its type (zero, nil, false, etc).
Well-known Timestamp types (google.protobuf.Timestamp) are returned as a struct containing fields with seconds and nanos fields (flag set to false). Setting this flag to true transforms the timestamps into a string representation in RFC3999 format.
Specifies the size of the client buffer reading the gRPC communication in bytes. If the value is unset, or 0, it uses its default (32KB). Use a negative value to disable the buffer, and if you do there won't be memory pre-allocation to read. To determine the right number, calculate the average size of the responses the gRPC client will receive.
Defines the naming convention used to format the request. Applies to query strings and JSON field names. By default, the gateway uses snake_case which makes use of the standard encoding/json package, while when you choose camelCase the protobuf/encoding deserialization is used instead.
Defines the naming convention used to format the returned data. By default, the gateway uses snake_case which makes use of the standard encoding/json package, while when you choose camelCase the protobuf/encoding deserialization is used instead.
When true, before sending a message to a host, it checks if the connection status is in a "transient failure" or "failure" state and tries to use a different host (from the service discovery or randomly from the list of hosts). If the connection is in a valid state, but an error happens when sending the gRPC message, it also tries to use a different host to retry sending the message. Depending on the host list, the retry attempts may go to the same host initially in a "bad state".
Enables the use of the sent body to fill the gRPC request. Take into account that when you set this flag to true a body is expected, and this body is consumed in the first backend. If the endpoint that uses this gRPC backend has additional backends (either gRPC or HTTP) that also expect to consume the payload, these requests might fail.
2 nested properties
Returns the HTTP status code of the backend (when there is only one). The headers are not returned.
Returns to the client details of a failing request.
Enterprise only. Allows you to set the different HTTP client options with the backend, like TLS, no redirect or connect via a proxy.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
4 nested properties
TLS options to connect to upstream services.
Set no_redirect to true if you don't want KrakenD to follow redirects and let the consuming user to receive the 30x status code.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
The proxy address used to forward the traffic. The address must contain the protocol and the port.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
Post the original body to the final URL after a 307 or a 308 redirection.
See: https://www.krakend.io/docs/enterprise/backends/http-client/
Invoke Amazon Lambda functions on a KrakenD endpoint call.
5 nested properties
An optional parameter to customize the Lambda endpoint to call. Useful when Localstack is used for testing instead of direct AWS usage.
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.
The endpoint {placeholder} that sets the function name, with the first letter uppercased. You have to choose between function_name and function_param_name but not both. If your endpoint defines the route /foo/{bar} the value of function_param_name must be Bar with the uppercased B.
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.
The AWS identifier region
Publishes to a topic using the desired driver.
1 nested properties
Topic URL according to the selected driver
Subscribes a backend using the desired driver.
1 nested properties
Subscription URL according to the selected driver
Enterprise only. Allows for fine grained control over a kafka publishing connection
2 nested properties
Enterprise only. Defines how to write messages to a Kafka cluster
HTTP status code to return for a successful write in the queue
Enterprise only. Allows for fine grained control over a kafka subcription connection
1 nested properties
Enterprise only. Defines how to read messages from a Kafka cluster
Enterprise only. Build and modify requests to communicate with SOAP services.
4 nested properties
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.
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.
The path to the Go template file you want to use to craft the body.
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.
Enterprise only. Allows you to fetch and serve static content from the disk instead of a remote server, and you can use it to mock data.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
2 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Whether to allow directory listings or not
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
7 nested properties
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
Enterprise only. 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/
1 nested properties
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
The Martian component allows you to modify requests and responses with static data through a simple DSL definition in the configuration file.
20 nested properties
The body.Modifier changes or sets the body of a request or response. The body must be uncompressed and Base64 encoded.
The cookie.Filter executes the contained modifier when a cookie is provided under the name.
Adds a cookie to a request or a response. If you set cookies in a response, the cookies are only set to the client when you use no-op encoding.
The fifo.Group holds a list of modifiers executed in first-in, first-out order.
The header.Blacklist removes the listed headers under names in the request and response of the backend.
The header.Copy lets you duplicate a header using another name
The header.Filter executes its contained modifier if the request or response contain a header that matches the defined name and value. The value is optional, and only the header’s existence evaluates when undefined.
The header.Modifier adds a new header or changes the value of an existing one.
The header.RegexFilter checks that a regular expression (RE2 syntax) passes on the target header and, if it does, executes the modifier.
The port.Filter executes its modifier only when the port matches the one used in the request. It does not support else.
The port.Modifier alters the request URL and Host header to use the provided port.
The priority.Group contains the modifiers you want to execute, but the order in which they are declared is unimportant. Instead, each modifier adds a priority attribute that defines the order in which they are run.
The querystring.Filter executes the modifier if the request or response contains a query string parameter that matches the defined name and value in the filter.
The querystring.Modifier adds a new query string or modifies existing ones in the request.
The stash.Modifier creates a new header (or replaces an existing one with a matching name) containing the value of the original URL and all its query string parameters.
The url.Filter executes its contained modifier if the request URL matches all of the provided parameters.
The url.Modifier allows you to change the URL despite what is set in the host and url_pattern combination.
The url.RegexFilter evaluates a regular expression (RE2 syntax) and executes the modifier desired when it matches, and the modifier declared under else when it does not.
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
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: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
1 nested properties
A list of modifiers you would like to apply to specific fields. The modifiers are evaluated and applied in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
[]Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
1 nested properties
The name of the plugin to load. Only one plugin is supported per backend.
See: https://www.krakend.io/docs/extending/injecting-plugins/
1 nested properties
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/enterprise/extending/middleware-plugins/
4 nested properties
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/
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/
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/
[]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/
2 nested properties
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.
Mark this backend as a shadow backend. Sending copies of the traffic but ignore its responses.
The circuit breaker prevents sending more traffic to a failing backend.
5 nested properties
Time window where the errors count, in seconds.
The CONSECUTIVE (not total) number of errors within the interval window to consider the backend unhealthy. All HTTP status codes different than 20x are considered an error, except for the no-op encoding that does not evaluate status codes and is limited to connectivity/networking, security and component errors. See the definition of error below.
For how many seconds the circuit breaker will wait before testing again if the backend is healthy.
Whether to log the changes of state of this circuit breaker or not.
A friendly name to follow this circuit breaker's activity in the logs.
Enterprise only. The HTTP circuit breaker prevents sending more traffic to a backend that is returning status codes that are considered errors.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
6 nested properties
Time window where the errors count, in seconds.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
The CONSECUTIVE (not total) number of errors within the interval window to consider the backend unhealthy. All HTTP status codes different than 20x are considered an error, except for the no-op encoding that does not evaluate status codes and is limited to connectivity/networking, security and component errors. See the definition of error below.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
For how many seconds the circuit breaker will wait before testing again if the backend is healthy. This number of seconds can also be read as the minimum cooldown of the backend interaction.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
A list of HTTP status codes that will be considered successful responses. Any response with a status code not in this list will be counted as an error by the circuit breaker.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Whether to log the changes of state of this circuit breaker or not.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
A friendly name to follow this circuit breaker's activity in the logs.
See: https://www.krakend.io/docs/enterprise/backends/http-circuit-breaker/
Enable in-memory caching for backend responses for as long as its Cache-Control header permits. Only safe methods are cached (GET or HEAD). The final backend URL and the Vary headers are used to create the caching key.
3 nested properties
To be released on open source on v2.10. The maximum number of items the LRU cache will store for this cache bucket before starting to do evictions. When max_items is declared, you must declare max_size as well.
To be released on open source on v2.10. The maximum number of bytes you allow the LRU cache to store for this cache bucket before starting to do evictions. This is not the total cache you allow to the system, but the number of bytes you reserve to this backend (or its shared neighbours). will store before starting to do evictions. When max_size is declared, you must declare max_items as well.
Allows different backend definitions with this flag set to true to reuse the store between them when the request is the same. Otherwise, each backend uses a private cache context that is not accessible by other endpoints. The cache definition is unique for every backend URL + Vary header combination.
Restrict the rate of requests KrakenD makes to your backends.
3 nested properties
The capacity according to the token bucket algorithm. Defines the maximum requests you can do in an instant (including the zero moment when you start the gateway), and can be larger or smaller than the max_rate. When unsure, use the same value of max_rate, so the maximum number of requests can be consumed at once.
Maximum requests per second you want to accept in this backend.
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.
Enterprise only. 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/
5 nested properties
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
Enterprise only. Add a specific Backend Log. Useful to see status codes, headers, and other information that come from your backends.
1 nested properties
Enables the Backend Log capabilities.
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
1 nested properties
Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
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/
Enterprise only. The response schema validator 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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
7 nested properties
List of all the backend objects called within this workflow. Each backend can initiate another workflow if needed.
An endpoint name for the workflow that will be used in logs. The name will be appended to the string /__workflow/ in the logs, and although it does not receive traffic under this route, it is necessary when you want to pass URL {params} to the nested backends.
The concurrent requests are an excellent technique to improve the response times and decrease error rates by requesting in parallel the same information multiple times. Yes, you make the same request to several backends instead of asking to just one. When the first backend returns the information, the remaining requests are canceled.
See: https://www.krakend.io/docs/endpoints/concurrent-requests/
Allow the workflow to continue with the rest of declared actions when there are errors (like security policies, network errors, etc). The default behavior of KrakenD is to abort an execution that has errors as soon as possible. If you use conditional backends and similar approaches, you might want to allow the gateway to go through all steps.
The gateway can work with several content types, even allowing your clients to choose how to consume the content. See the supported encodings
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.
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/
An array with all the available hosts to load balance 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.
A second level of header filtering that defines the list of all headers allowed to reach this backend when different than the endpoint.
By default, all headers in the endpoint input_headers reach the backend, unless otherwise specified here. An empty list [] is considered a zero-value and allows all headers to pass. Use [""] to explicitly remove all headers. See headers forwarding
[]A second level of query string filtering that defines the list of all query strings allowed to reach this backend when different than the endpoint.
By default, all query strings in the endpoint input_query_strings reach the backend, unless otherwise specified here. An empty list [] is considered a zero-value and allows all headers to pass. Use [""] to explicitly remove all query strings. See query strings forwarding
[]Set to true when your API does not return an object {} but a collection []
See: https://www.krakend.io/docs/backends/data-manipulation/
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/
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.
The Service Discovery system to resolve your backend services. Defaults to static (no external Service Discovery). Use dns to use DNS SRV records. Use dns-shared to share the DNS resolution between backends using the same hosts.
The Service Discovery scheme to connect to your backend services.
Removes the matching object from the reponse and returns only its contents.
See: https://www.krakend.io/docs/backends/data-manipulation/
The Async AMQP component enables the AMQP driver for the Async functionality.
The entity name where messages are retrieved (it will be created, or it must have a topic type if already exists).
The connection string, ends in slash. E.g: amqp://user:password@host:5672/.
The queue name.
When KrakenD retrieves the messages, regardless of the success or failure of the operation, it marks them as ACK. When auto ACK is not used, only successful backend responses do the ACK, and failing messages are requeued. Defaults to false.
When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it's the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won't exist and future connections will recreate it again.
Durable queues will survive server restarts and remain when there are no remaining consumers or bindings. Most of the times true is recommended, but depends on the use case.
When true, AMQP will allow a single KrakenD client to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.
When true, messages that cannot be processed are discarded instead of being sent back to the queue. This is useful for scenarios where you want to avoid reprocessing failed messages.
The no_local flag is not supported by RabbitMQ.
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.
The number of messages you want to prefetch prior to consume them.
The number of bytes you want to use to prefetch messages.
Enterprise only. Defines how to read messages from a Kafka cluster for an async agent
Enterprise only. Defines how to connect to a Kafka cluster
12 nested properties
TLS options to connect to upstream services.
8 nested properties
By default, KrakenD verifies every SSL connection. This option allows you to connect to backends considered insecure, for instance when you are using self-signed certificates
An array with all the CA certificates you would like to validate the server you are connecting to.
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all client certificates available when fetching data from the upstream service.
The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.
Enterprise only. SASL base authentication with broker: there are multiple SASL authentication methods but the current implementation is limited to plaintext (SASL/PLAIN) authentication
7 nested properties
Name of the enabled SASL mechanism
Kafka > 1.x should use SASL V1, except on Azure EventHub which uses V0
Whether or not to send the Kafka SASL handshake first if enabled. You should only set this to false if you're using a non-Kafka SASL proxy
Auth Identity is an (optional) authorization identity (authzid) to use for SASL/PLAIN authentication (if different from User) when an authenticated user is permitted to act as the presented alternative user. See RFC4616 for details
Authentication identity (authcid) to present for SASL/PLAIN or SASL/SCRAM authentication
Password for SASL/PLAIN authentication
Authz id used for SASL/SCRAM authentication
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.
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.
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.
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.
A name to give to the client stablishing the connection
A name to identify the rack we are connecting from
The number of events to buffer in internal and external channels. This permits the producer and consumer to continue processing some messages in the background while user code is working, greatly improving throughput
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.
When a disconnection happens, the client needs to refresh its metadata to know the current state of the kafka cluster (effectively the number of attempts to reconnect)
Enterprise only. Defines the detaisl for a Kafka consumer group.
8 nested properties
Name of the consumer group to use
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.
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.
Priority-ordered list of client-side consumer group balancing strategies that will be offered to the coordinator. The first strategy that all group members support will be chosen by the leader. Options are: range, roundrobin, and sticky
[
"range"
]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.
Support KIP-345
The default number of message bytes to fetch from the broker in each request (default 1MB). This should be larger than the majority of your messages, or else the consumer will spend a lot of time negotiating sizes and not actually consuming. Similar to the JVM's fetch.message.max.bytes
Supports 2 modes: read_commited to consume and return all messages in message channel, and read_uncommited to hide messages that are part of an aborted transaction
Name of the header where the kafka message key value is written
Async agents are routines listening to queues or PubSub systems that react to new events and push data to your backends. Through async agents, you can start a lot of consumers to process your events autonomously.
Enterprise only. Declares the current endpoint as an MCP server entry point.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
The MCP server you want to attach to this endpoint. When you add this namespace, the endpoint becomes the MCP server entry point URL. The name used must match the name in the ai/mcp configuration in the root level.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
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/
Absolute Path to the htpasswd filename (recommended) or relative ./ to the workdir (less secure).
See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/
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/
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.
The hashing algorithm used by the issuer. Usually RS256. The algorithm you choose directly affects the CPU consumption.
List of all the specific keys that need signing (e.g., refresh_token and access_token).
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/
Override the default cipher suites (see JWT validation). Unless you have a legacy JWK, you don't need to set this value.
[
49199,
49195,
49200,
49196,
52392,
52393
]The cyphering key.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
Use JSON format instead of the compact form JWT provides.
See: https://www.krakend.io/docs/enterprise/authorization/jwt-validation/
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.
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/
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/
The URL to the JWK endpoint with the private keys used to sign the token.
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.
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/
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/
The hashing algorithm used by the token issuer.
See: https://www.krakend.io/docs/authorization/jwt-validation/
Reject tokens that do not contain ALL audiences declared in the list.
See: https://www.krakend.io/docs/authorization/jwt-validation/
Allows to parse the token from a custom header.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
The cache duration in seconds when the cache is enabled. 15 minutes when unset.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
[
49199,
49195,
49200,
49196,
52392,
52393
]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/
The cyphering key.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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.
When set, tokens not matching the issuer are rejected.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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/
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/
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 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/
Allows strategies other than kid to load keys.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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.
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/
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/
When set to true, the JWT claims that are propagated to the backend will preserve their array structure as multi-value headers, if applies. If set to false, arrays will be converted to comma-separated strings.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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/
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/
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/
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/
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/
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/
Enterprise only. Generates OpenAPI documentation automatically through krakend openapi export command.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
An introductory, optionally verbose, explanation supporting CommonMark 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/
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/
A starting path that is appended to any endpoint.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The JSON Schemas you can reuse inside endpoint definitions using ref. You can either pass the JSON Schema object, or a bas64 string.
Email where users of your API can write to.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact name.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact URL that users of your API can read.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the cookie used under components securitySchemes.
Allows you to add custom security schemes under components/securitySchemes in the generated OpenAPI spec. This is useful when you want to define your own security schemes, different from the built-in ones (e.g., jwt, apikey, cookie, etc.). When the property is in the service level you must declare the schema (e.g., "OAuth2Security":{...}), and when it is in the endpoint you should only write the object name with not properties inside, e.g, {"OAuth2Security":{}.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
By default, KrakenD adds a 500 and a 200 response definition to each endpoint. Set this property to true if you want to avoid this behavior.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the headers allowed in the endpoint. Make sure to include the same headers in the endpoint's input_headers.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The hostname where you will publish your API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the JWT key used under components securitySchemes.
The license name (e.g.: Apache License)
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The URL where the license is hosted
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the URL parameters (e.g.: /foo/{param}) required in the endpoint. Make sure to include to write the param exactly as in the endpoint definition.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed 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/
Describes the payload 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.This property is an array because you can document requests with multiple content types.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The list of schemes supported by the API, e.g. http or https
See: https://www.krakend.io/docs/enterprise/developer/openapi/
[
"http"
]The list of servers where the API is hosted. The server URL can be a relative path, e.g., /v1 or an absolute path. The URL might contain {variables}, although these are only recognized by OpenAPI and to KrakenD they are just literal strings because it does not use them.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
A short summary for the endpoint. Use the description field for the longest explanation.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed description for the tags classifiying endpoints when generating the OpenAPI spec.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The URL to the terms of service for using this API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Enterprise only. Generates postman documentation automatically through krakend postman export command.
See: https://www.krakend.io/docs/enterprise/developer/postman/
An introductory, optionally verbose, explanation supporting Markdown syntax. If you'd like to load an external markdown file, you can use flexible configuration, for instance "description": {{include "postman/intro.md" | toJson }}
See: https://www.krakend.io/docs/enterprise/developer/postman/
The folder name where you want to put this endpoint. If you defined folders at the service level, use the same name to reuse their name and description
The name of the endpoint you are generating. If you don't set any name the last member path is used.
See: https://www.krakend.io/docs/enterprise/developer/postman/
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Defines the maximum number of tokens a bucket can hold, 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.
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.
These are the number of routines that search for and remove outdated rate limit counters. The more routine(s) you add, the faster the memory optimization is completed, but the more CPU it will consume. Generally speaking, a single thread is more than enough because the delete operation is very fast, even with a large number of counters. This is an advanced micro-optimization setting that you should use with caution.
Defines the maximum number of tokens a bucket can hold, 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.
Number of tokens you add to the 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.
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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.
All rate limit counters are stored in memory in groups (shards). All counters in the same shard share a mutex (which controls that one counter is modified at a time), and this helps with contention. Having, for instance, 2048 shards (default) and 1M users connected concurrently (same instant) means that each user will need to coordinate writes in their counter with an average of under 500 other users (1M/2048=489). Lowering the shards might increase contention and latency but free additional memory. This is an advanced micro-optimization setting that should be used with caution.
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.
Enterprise only. Redis-backed service ratelimit
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Number of tokens you add to the 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/enterprise/throttling/global-rate-limit/
The connection pool name or cluster name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
The connection pool name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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/enterprise/throttling/global-rate-limit/
Whether you want to allow a request to continue when the Redis connection is failing or not. The default behavior blocks the request if Redis is not responding correctly
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/enterprise/throttling/global-rate-limit/
Enterprise only. Apply ratelimit based on tier match.
The header name containing the tier name. The string you provide is case-insensitive. If you need to take the value from a place that is not a header (a token, an API key), you must use propagate functions in the components that convert values to internal headers.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
The list of all tier definitions and limits for each. Each item in the list is a tier object.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
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.
An array with EXACT MATCHES of trusted user agents that can connect.
[]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.
An array with EXACT MATCHES of undesired bots, to reject immediately.
[]Whether to consider an empty user-agent a bot (and reject it) or not.
An array with all the regular expressions that define bots. Matching bots are rejected.
[]Define Cross-Origin Resource Sharing (CORS) configuration to send additional HTTP headers to tell browsers if they can use resources from a different origin.
When requests can include user credentials like cookies, HTTP authentication or client side SSL certificates.
An array with the headers allowed, but Originis always appended to the list. Requests with headers not in this list are rejected.
[]An array with all the HTTP methods allowed, in uppercase. Possible values are GET, HEAD,POST,PUT,PATCH,DELETE, or OPTIONS
[
"GET",
"HEAD",
"POST"
]An array with all the origins allowed, the use of one * is permitted to allow groups of hosts. Examples of values are <https://example.com>, <https://example.*>, <https://*.example.com> or just *` (any origin).
[
"*"
]Indicates whether to accept cross-origin requests over a private network.
Show debugging information in the logger, use it only during development.
List of headers that are safe to expose to the API of a CORS API specification.
[
"Content-Length",
"Content-Type"
]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.
Instructs preflight to let other potential next handlers to process the OPTIONS method. Turn this on when you set the auto_opts flag in the router to true.
The HTTP status code that is considered a success.
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.
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.
[]Treat the allowed hosts list as regular expressions.
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
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.
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.
Force a STS Header even if using plain HTTP.
Set to true to enable clickjacking protection, together with custom_frame_options_value.
A set of header keys that may hold a proxied hostname value for the request.
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.).
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.
Allows the Referrer-Policy header with the value to be set with a custom value.
When the SSL redirect is true, the host where the request is redirected to.
Header keys with associated values that would indicate a valid https request. Useful when using Nginx, e.g: "X-Forwarded-Proto": "https"
Redirect any request that is not using HTTPS
Set to true when you want the includeSubdomains be appended to the Strict-Transport-Security header.
Enable this policy by setting the max-age of the Strict-Transport-Security header. Setting to 0 disables HSTS.
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Enterprise only. Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
2 nested properties
5 nested properties
Whether you want to enable detailed metrics for the HTTP connection phase or not. Includes times to connect, DNS querying, and the TLS handshake.
Whether to turn off the metrics or not. Setting this to true means stop reporting any data.
Whether you want to enable metrics for the response reading payload or not (HTTP connection not taken into account).
Whether you want to enable metrics for the actual HTTP request for the backend or not (manipulation not taken into account). This is the time your backend needs to produce a result.
A list of tags or labels you want to associate with these metrics.
7 nested properties
Whether you want to add detailed trace attributes for the HTTP connection phase or not. Includes times to connect, DNS querying, and the TLS handshake.
Whether to turn off the traces or not. Setting this to true means stop reporting any data.
Whether you want to add trace attributes for the response reading payload or not (HTTP connection not taken into account).
Whether you want to report the final headers that reached the backend.
Whether you want to add trace attributes for the actual HTTP request for the backend or not (manipulation not taken into account). This is the time your backend needs to produce a result.
A list of headers you want to skip when reporting the headers that reached the backend. This is useful to avoid reporting sensitive data.
A list of tags or labels you want to associate to these traces.
Enterprise only. Override exporter configuration for this endpoint
4 nested properties
Overrides the metrics exporters used in this endpoint
Override how often you want to report and flush the metrics in seconds.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Overrides the trace exporters used in this endpoint
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/
Overrides the global configuration for this endpoint.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
2 nested properties
Static attributes you want to pass for metrics. Overrides the metrics_static_attributes defined at the service level.
Static attributes you want to pass for traces. Overrides the traces_static_attributes defined at the service level.
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/
6 nested properties
Whether you want to disable all metrics in this endpoint or not.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Whether you want to disable all traces in this endpoint or not.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Static attributes you want to pass for metrics.
Whether you want to report all headers that passed from the request to the proxy layer (input_headers policy in the endpoint plus KrakenD's headers).
A list of headers you want to skip when reporting headers passed to the proxy layer. This is useful to avoid reporting sensitive data.
Static attributes you want to pass for traces.
Enterprise only. Enables websocket communication.
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'
Whether to send notification events to the backend or not when a user establishes a new Websockets connection.
Disables the OpenTelemetry metrics for the websocket connections.
Whether to send notification events to the backend or not when users disconnect from their Websockets connection.
When the value is set to true the communication is set one to one, and disables multiplexing. One client to KrakenD opens one connection to the backend. This mode of operation is sub-optimal in comparison to multiplexing.
Defines which input headers are allowed to pass to the backend. You don't need to declare the input_headers at the endpoint. Use * to pass all headers (not recommended, use explicit values instead). There are a few headers that won't be propagated regardless of your configuration, which are: Upgrade, Connection, Sec-Websocket-Extensions, Sec-Websocket-Version, and Sec-Websocket-Key.
[]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.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken websockets server. When the maximum retries are reached, the gateway gives up the connection for good. Minimum value is 1 retry, or use <= 0 for unlimited retries.
Sets the maximum number of messages each end-user can have in the buffer waiting to be processed. As this is a per-end-user 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.
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.
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.
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.
Provides an error {'error':'reason here'} to the client when KrakenD was unable to send the message to the backend.
The list of subprotocols that the client can use to connect to the websocket.
[]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.
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.
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.
Enterprise only. Declares the current endpoint as an MCP server entry point.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
1 nested properties
The MCP server you want to attach to this endpoint. When you add this namespace, the endpoint becomes the MCP server entry point URL. The name used must match the name in the ai/mcp configuration in the root level.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
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/
4 nested properties
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/
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/
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/
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/
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/
2 nested properties
Absolute Path to the htpasswd filename (recommended) or relative ./ to the workdir (less secure).
See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/
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/
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.
13 nested properties
The hashing algorithm used by the issuer. Usually RS256. The algorithm you choose directly affects the CPU consumption.
List of all the specific keys that need signing (e.g., refresh_token and access_token).
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/
Override the default cipher suites (see JWT validation). Unless you have a legacy JWK, you don't need to set this value.
[
49199,
49195,
49200,
49196,
52392,
52393
]The cyphering key.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
Use JSON format instead of the compact form JWT provides.
See: https://www.krakend.io/docs/enterprise/authorization/jwt-validation/
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.
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/
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/
The URL to the JWK endpoint with the private keys used to sign the token.
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.
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/
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/
27 nested properties
The hashing algorithm used by the token issuer.
See: https://www.krakend.io/docs/authorization/jwt-validation/
Reject tokens that do not contain ALL audiences declared in the list.
See: https://www.krakend.io/docs/authorization/jwt-validation/
Allows to parse the token from a custom header.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
The cache duration in seconds when the cache is enabled. 15 minutes when unset.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
[
49199,
49195,
49200,
49196,
52392,
52393
]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/
The cyphering key.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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.
When set, tokens not matching the issuer are rejected.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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/
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/
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 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/
Allows strategies other than kid to load keys.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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.
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/
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/
When set to true, the JWT claims that are propagated to the backend will preserve their array structure as multi-value headers, if applies. If set to false, arrays will be converted to comma-separated strings.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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/
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/
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/
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/
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/
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/
Enterprise only. Generates OpenAPI documentation automatically through krakend openapi export command.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
28 nested properties
An introductory, optionally verbose, explanation supporting CommonMark 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/
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/
A starting path that is appended to any endpoint.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The JSON Schemas you can reuse inside endpoint definitions using ref. You can either pass the JSON Schema object, or a bas64 string.
Email where users of your API can write to.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact name.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact URL that users of your API can read.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the cookie used under components securitySchemes.
Allows you to add custom security schemes under components/securitySchemes in the generated OpenAPI spec. This is useful when you want to define your own security schemes, different from the built-in ones (e.g., jwt, apikey, cookie, etc.). When the property is in the service level you must declare the schema (e.g., "OAuth2Security":{...}), and when it is in the endpoint you should only write the object name with not properties inside, e.g, {"OAuth2Security":{}.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
By default, KrakenD adds a 500 and a 200 response definition to each endpoint. Set this property to true if you want to avoid this behavior.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the headers allowed in the endpoint. Make sure to include the same headers in the endpoint's input_headers.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The hostname where you will publish your API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the JWT key used under components securitySchemes.
The license name (e.g.: Apache License)
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The URL where the license is hosted
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the URL parameters (e.g.: /foo/{param}) required in the endpoint. Make sure to include to write the param exactly as in the endpoint definition.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed 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/
Describes the payload 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.This property is an array because you can document requests with multiple content types.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The list of schemes supported by the API, e.g. http or https
See: https://www.krakend.io/docs/enterprise/developer/openapi/
[
"http"
]The list of servers where the API is hosted. The server URL can be a relative path, e.g., /v1 or an absolute path. The URL might contain {variables}, although these are only recognized by OpenAPI and to KrakenD they are just literal strings because it does not use them.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
A short summary for the endpoint. Use the description field for the longest explanation.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed description for the tags classifiying endpoints when generating the OpenAPI spec.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The URL to the terms of service for using this API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Enterprise only. Generates postman documentation automatically through krakend postman export command.
See: https://www.krakend.io/docs/enterprise/developer/postman/
3 nested properties
An introductory, optionally verbose, explanation supporting Markdown syntax. If you'd like to load an external markdown file, you can use flexible configuration, for instance "description": {{include "postman/intro.md" | toJson }}
See: https://www.krakend.io/docs/enterprise/developer/postman/
The folder name where you want to put this endpoint. If you defined folders at the service level, use the same name to reuse their name and description
The name of the endpoint you are generating. If you don't set any name the last member path is used.
See: https://www.krakend.io/docs/enterprise/developer/postman/
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
7 nested properties
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. 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/
1 nested properties
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
1 nested properties
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
1 nested properties
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
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: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
1 nested properties
A list of modifiers you would like to apply to specific fields. The modifiers are evaluated and applied in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
[]Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
1 nested properties
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/enterprise/extending/middleware-plugins/
4 nested properties
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/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
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/
[]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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
Fine tune different options for the proxy phase of the API request/response flow.
7 nested properties
For custom builds of KrakenD only
Enterprise only. Decompresses any Gzipped content before sending it to the backend when the Content-Encoding has gzip in the first position. You can also set this value globally at the service level.
See: https://www.krakend.io/docs/service-settings/router-options/
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.
Enterprise only. Limits the maximum number of bytes a user can send to the endpoint. 0 means no limit. You can also set this value globally at the service level.
See: https://www.krakend.io/docs/service-settings/router-options/
When set to true, instead of fetching all backend content in parallel, the calls are made in order (sequentially), allowing you to chain backend requests and making calls dependent one of each other. If any of the calls fail, the remaining ones are aborted.
See: https://www.krakend.io/docs/endpoints/sequential-proxy/
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/
The static proxy injects static data in the final response when the selected strategy matches.
2 nested properties
The static data (as a JSON object) that you will return.
One of the supported strategies
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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.
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.
These are the number of routines that search for and remove outdated rate limit counters. The more routine(s) you add, the faster the memory optimization is completed, but the more CPU it will consume. Generally speaking, a single thread is more than enough because the delete operation is very fast, even with a large number of counters. This is an advanced micro-optimization setting that you should use with caution.
Defines the maximum number of tokens a bucket can hold, 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.
Number of tokens you add to the 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.
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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.
All rate limit counters are stored in memory in groups (shards). All counters in the same shard share a mutex (which controls that one counter is modified at a time), and this helps with contention. Having, for instance, 2048 shards (default) and 1M users connected concurrently (same instant) means that each user will need to coordinate writes in their counter with an average of under 500 other users (1M/2048=489). Lowering the shards might increase contention and latency but free additional memory. This is an advanced micro-optimization setting that should be used with caution.
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.
Enterprise only. Redis-backed service ratelimit
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Number of tokens you add to the 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/enterprise/throttling/global-rate-limit/
The connection pool name or cluster name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
The connection pool name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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/enterprise/throttling/global-rate-limit/
Whether you want to allow a request to continue when the Redis connection is failing or not. The default behavior blocks the request if Redis is not responding correctly
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/enterprise/throttling/global-rate-limit/
Enterprise only. Apply ratelimit based on tier match.
2 nested properties
The header name containing the tier name. The string you provide is case-insensitive. If you need to take the value from a place that is not a header (a token, an API key), you must use propagate functions in the components that convert values to internal headers.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
The list of all tier definitions and limits for each. Each item in the list is a tier object.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
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.
5 nested properties
An array with EXACT MATCHES of trusted user agents that can connect.
[]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.
An array with EXACT MATCHES of undesired bots, to reject immediately.
[]Whether to consider an empty user-agent a bot (and reject it) or not.
An array with all the regular expressions that define bots. Matching bots are rejected.
[]Define Cross-Origin Resource Sharing (CORS) configuration to send additional HTTP headers to tell browsers if they can use resources from a different origin.
10 nested properties
When requests can include user credentials like cookies, HTTP authentication or client side SSL certificates.
An array with the headers allowed, but Originis always appended to the list. Requests with headers not in this list are rejected.
[]An array with all the HTTP methods allowed, in uppercase. Possible values are GET, HEAD,POST,PUT,PATCH,DELETE, or OPTIONS
[
"GET",
"HEAD",
"POST"
]An array with all the origins allowed, the use of one * is permitted to allow groups of hosts. Examples of values are <https://example.com>, <https://example.*>, <https://*.example.com> or just *` (any origin).
[
"*"
]Indicates whether to accept cross-origin requests over a private network.
Show debugging information in the logger, use it only during development.
List of headers that are safe to expose to the API of a CORS API specification.
[
"Content-Length",
"Content-Type"
]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.
Instructs preflight to let other potential next handlers to process the OPTIONS method. Turn this on when you set the auto_opts flag in the router to true.
The HTTP status code that is considered a success.
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.
17 nested properties
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.
[]Treat the allowed hosts list as regular expressions.
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
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.
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.
Force a STS Header even if using plain HTTP.
Set to true to enable clickjacking protection, together with custom_frame_options_value.
A set of header keys that may hold a proxied hostname value for the request.
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.).
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.
Allows the Referrer-Policy header with the value to be set with a custom value.
When the SSL redirect is true, the host where the request is redirected to.
Header keys with associated values that would indicate a valid https request. Useful when using Nginx, e.g: "X-Forwarded-Proto": "https"
Redirect any request that is not using HTTPS
Set to true when you want the includeSubdomains be appended to the Strict-Transport-Security header.
Enable this policy by setting the max-age of the Strict-Transport-Security header. Setting to 0 disables HSTS.
Enterprise only. 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/
6 nested properties
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
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/
1 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
2 nested properties
An array with all the policies to evaluate. Each policy is represented as a string
See: https://www.krakend.io/docs/enterprise/security-policies/
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
4 nested properties
Enterprise only. Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
2 nested properties
Enterprise only. Override exporter configuration for this endpoint
4 nested properties
Overrides the metrics exporters used in this endpoint
Override how often you want to report and flush the metrics in seconds.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Overrides the trace exporters used in this endpoint
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/
Overrides the global configuration for this endpoint.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
2 nested properties
Static attributes you want to pass for metrics. Overrides the metrics_static_attributes defined at the service level.
Static attributes you want to pass for traces. Overrides the traces_static_attributes defined at the service level.
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/
6 nested properties
Whether you want to disable all metrics in this endpoint or not.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Whether you want to disable all traces in this endpoint or not.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
Static attributes you want to pass for metrics.
Whether you want to report all headers that passed from the request to the proxy layer (input_headers policy in the endpoint plus KrakenD's headers).
A list of headers you want to skip when reporting headers passed to the proxy layer. This is useful to avoid reporting sensitive data.
Static attributes you want to pass for traces.
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/
Apply automatic validations using a JSON Schema definition 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.
Enterprise only. The response schema validator 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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
3 nested properties
The error message you want to show when the validation fails. Set it to an empty string "" to show the JSON-schema validation error.
The Content-Type header you want to set back in the response when you are setting a custom body
The HTTP status code you want to set back in the response.
Enterprise only. Enables websocket communication.
17 nested properties
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'
Whether to send notification events to the backend or not when a user establishes a new Websockets connection.
Disables the OpenTelemetry metrics for the websocket connections.
Whether to send notification events to the backend or not when users disconnect from their Websockets connection.
When the value is set to true the communication is set one to one, and disables multiplexing. One client to KrakenD opens one connection to the backend. This mode of operation is sub-optimal in comparison to multiplexing.
Defines which input headers are allowed to pass to the backend. You don't need to declare the input_headers at the endpoint. Use * to pass all headers (not recommended, use explicit values instead). There are a few headers that won't be propagated regardless of your configuration, which are: Upgrade, Connection, Sec-Websocket-Extensions, Sec-Websocket-Version, and Sec-Websocket-Key.
[]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.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken websockets server. When the maximum retries are reached, the gateway gives up the connection for good. Minimum value is 1 retry, or use <= 0 for unlimited retries.
Sets the maximum number of messages each end-user can have in the buffer waiting to be processed. As this is a per-end-user 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.
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.
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.
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.
Provides an error {'error':'reason here'} to the client when KrakenD was unable to send the message to the backend.
The list of subprotocols that the client can use to connect to the websocket.
[]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.
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.
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.
An array with all the backend services you want to use in this endpoint. See the backend object documentation to know all the available options, they are omitted here for brevity.
The path of the URL you want to expose. The path is case-sensitive and should start with a slash /. You can use {placeholders} to allow dynamic variables. For example: /foo/{var}/baz. You can also add an ending /* in the path to enable wildcards. Enterprise only.
The router will try to automatically redirect calls to endpoints with an incorrect case or incorrect trailing slash to its correct version offering a 301. There are no guarantees that it will succeed and the request might even fail completely while trying (and log an ugly error with a trace). The safest option is to disable automatic redirections by setting to true the flags disable_redirect_fixed_path and disable_redirect_trailing_slash in the router options.
Limitations: URLs do not support colons : in their definition. All {vars} are meant to be isolated in the path and not to be used to build words, like in /file.{ext} See disable_rest for that usage.
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.
The concurrent requests are an excellent technique to improve the response times and decrease error rates by requesting in parallel the same information multiple times. Yes, you make the same request to several backends instead of asking to just one. When the first backend returns the information, the remaining requests are canceled.
See: https://www.krakend.io/docs/endpoints/concurrent-requests/
31 nested properties
Enterprise only. Declares the current endpoint as an MCP server entry point.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
1 nested properties
The MCP server you want to attach to this endpoint. When you add this namespace, the endpoint becomes the MCP server entry point URL. The name used must match the name in the ai/mcp configuration in the root level.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
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/
4 nested properties
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/
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/
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/
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/
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/
2 nested properties
Absolute Path to the htpasswd filename (recommended) or relative ./ to the workdir (less secure).
See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/
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/
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.
13 nested properties
The hashing algorithm used by the issuer. Usually RS256. The algorithm you choose directly affects the CPU consumption.
List of all the specific keys that need signing (e.g., refresh_token and access_token).
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/
Override the default cipher suites (see JWT validation). Unless you have a legacy JWK, you don't need to set this value.
[
49199,
49195,
49200,
49196,
52392,
52393
]The cyphering key.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
Use JSON format instead of the compact form JWT provides.
See: https://www.krakend.io/docs/enterprise/authorization/jwt-validation/
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.
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/
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/
The URL to the JWK endpoint with the private keys used to sign the token.
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.
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/
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/
27 nested properties
The hashing algorithm used by the token issuer.
See: https://www.krakend.io/docs/authorization/jwt-validation/
Reject tokens that do not contain ALL audiences declared in the list.
See: https://www.krakend.io/docs/authorization/jwt-validation/
Allows to parse the token from a custom header.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
The cache duration in seconds when the cache is enabled. 15 minutes when unset.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
[
49199,
49195,
49200,
49196,
52392,
52393
]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/
The cyphering key.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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.
When set, tokens not matching the issuer are rejected.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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/
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/
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 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/
Allows strategies other than kid to load keys.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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.
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/
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/
When set to true, the JWT claims that are propagated to the backend will preserve their array structure as multi-value headers, if applies. If set to false, arrays will be converted to comma-separated strings.
See: https://www.krakend.io/docs/authorization/jwt-validation/
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/
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/
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/
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/
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/
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/
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/
Enterprise only. Generates OpenAPI documentation automatically through krakend openapi export command.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
28 nested properties
An introductory, optionally verbose, explanation supporting CommonMark 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/
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/
A starting path that is appended to any endpoint.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The JSON Schemas you can reuse inside endpoint definitions using ref. You can either pass the JSON Schema object, or a bas64 string.
Email where users of your API can write to.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact name.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact URL that users of your API can read.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the cookie used under components securitySchemes.
Allows you to add custom security schemes under components/securitySchemes in the generated OpenAPI spec. This is useful when you want to define your own security schemes, different from the built-in ones (e.g., jwt, apikey, cookie, etc.). When the property is in the service level you must declare the schema (e.g., "OAuth2Security":{...}), and when it is in the endpoint you should only write the object name with not properties inside, e.g, {"OAuth2Security":{}.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
By default, KrakenD adds a 500 and a 200 response definition to each endpoint. Set this property to true if you want to avoid this behavior.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the headers allowed in the endpoint. Make sure to include the same headers in the endpoint's input_headers.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The hostname where you will publish your API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the JWT key used under components securitySchemes.
The license name (e.g.: Apache License)
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The URL where the license is hosted
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the URL parameters (e.g.: /foo/{param}) required in the endpoint. Make sure to include to write the param exactly as in the endpoint definition.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed 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/
Describes the payload 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.This property is an array because you can document requests with multiple content types.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The list of schemes supported by the API, e.g. http or https
See: https://www.krakend.io/docs/enterprise/developer/openapi/
[
"http"
]The list of servers where the API is hosted. The server URL can be a relative path, e.g., /v1 or an absolute path. The URL might contain {variables}, although these are only recognized by OpenAPI and to KrakenD they are just literal strings because it does not use them.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
A short summary for the endpoint. Use the description field for the longest explanation.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed description for the tags classifiying endpoints when generating the OpenAPI spec.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The URL to the terms of service for using this API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Enterprise only. Generates postman documentation automatically through krakend postman export command.
See: https://www.krakend.io/docs/enterprise/developer/postman/
3 nested properties
An introductory, optionally verbose, explanation supporting Markdown syntax. If you'd like to load an external markdown file, you can use flexible configuration, for instance "description": {{include "postman/intro.md" | toJson }}
See: https://www.krakend.io/docs/enterprise/developer/postman/
The folder name where you want to put this endpoint. If you defined folders at the service level, use the same name to reuse their name and description
The name of the endpoint you are generating. If you don't set any name the last member path is used.
See: https://www.krakend.io/docs/enterprise/developer/postman/
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
7 nested properties
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. 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/
1 nested properties
The JMESPath expression you want to apply to this endpoint.
See: https://www.krakend.io/docs/enterprise/endpoints/jmespath/
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
1 nested properties
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
1 nested properties
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
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: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
1 nested properties
A list of modifiers you would like to apply to specific fields. The modifiers are evaluated and applied in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/content-replacer/
[]Enterprise only. Crafts the body/payload using a templating system.
4 nested properties
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/
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/
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/
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/
1 nested properties
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/enterprise/extending/middleware-plugins/
4 nested properties
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/
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/
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/
[]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/
Fine tune different options for the proxy phase of the API request/response flow.
7 nested properties
For custom builds of KrakenD only
Enterprise only. Decompresses any Gzipped content before sending it to the backend when the Content-Encoding has gzip in the first position. You can also set this value globally at the service level.
See: https://www.krakend.io/docs/service-settings/router-options/
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.
Enterprise only. Limits the maximum number of bytes a user can send to the endpoint. 0 means no limit. You can also set this value globally at the service level.
See: https://www.krakend.io/docs/service-settings/router-options/
When set to true, instead of fetching all backend content in parallel, the calls are made in order (sequentially), allowing you to chain backend requests and making calls dependent one of each other. If any of the calls fail, the remaining ones are aborted.
See: https://www.krakend.io/docs/endpoints/sequential-proxy/
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/
The static proxy injects static data in the final response when the selected strategy matches.
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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.
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.
These are the number of routines that search for and remove outdated rate limit counters. The more routine(s) you add, the faster the memory optimization is completed, but the more CPU it will consume. Generally speaking, a single thread is more than enough because the delete operation is very fast, even with a large number of counters. This is an advanced micro-optimization setting that you should use with caution.
Defines the maximum number of tokens a bucket can hold, 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.
Number of tokens you add to the 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.
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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.
All rate limit counters are stored in memory in groups (shards). All counters in the same shard share a mutex (which controls that one counter is modified at a time), and this helps with contention. Having, for instance, 2048 shards (default) and 1M users connected concurrently (same instant) means that each user will need to coordinate writes in their counter with an average of under 500 other users (1M/2048=489). Lowering the shards might increase contention and latency but free additional memory. This is an advanced micro-optimization setting that should be used with caution.
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.
Enterprise only. Redis-backed service ratelimit
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Number of tokens you add to the 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/enterprise/throttling/global-rate-limit/
The connection pool name or cluster name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
The connection pool name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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/enterprise/throttling/global-rate-limit/
Whether you want to allow a request to continue when the Redis connection is failing or not. The default behavior blocks the request if Redis is not responding correctly
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/enterprise/throttling/global-rate-limit/
Enterprise only. Apply ratelimit based on tier match.
2 nested properties
The header name containing the tier name. The string you provide is case-insensitive. If you need to take the value from a place that is not a header (a token, an API key), you must use propagate functions in the components that convert values to internal headers.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
The list of all tier definitions and limits for each. Each item in the list is a tier object.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
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.
5 nested properties
An array with EXACT MATCHES of trusted user agents that can connect.
[]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.
An array with EXACT MATCHES of undesired bots, to reject immediately.
[]Whether to consider an empty user-agent a bot (and reject it) or not.
An array with all the regular expressions that define bots. Matching bots are rejected.
[]Define Cross-Origin Resource Sharing (CORS) configuration to send additional HTTP headers to tell browsers if they can use resources from a different origin.
10 nested properties
When requests can include user credentials like cookies, HTTP authentication or client side SSL certificates.
An array with the headers allowed, but Originis always appended to the list. Requests with headers not in this list are rejected.
[]An array with all the HTTP methods allowed, in uppercase. Possible values are GET, HEAD,POST,PUT,PATCH,DELETE, or OPTIONS
[
"GET",
"HEAD",
"POST"
]An array with all the origins allowed, the use of one * is permitted to allow groups of hosts. Examples of values are <https://example.com>, <https://example.*>, <https://*.example.com> or just *` (any origin).
[
"*"
]Indicates whether to accept cross-origin requests over a private network.
Show debugging information in the logger, use it only during development.
List of headers that are safe to expose to the API of a CORS API specification.
[
"Content-Length",
"Content-Type"
]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.
Instructs preflight to let other potential next handlers to process the OPTIONS method. Turn this on when you set the auto_opts flag in the router to true.
The HTTP status code that is considered a success.
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.
17 nested properties
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.
[]Treat the allowed hosts list as regular expressions.
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
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.
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.
Force a STS Header even if using plain HTTP.
Set to true to enable clickjacking protection, together with custom_frame_options_value.
A set of header keys that may hold a proxied hostname value for the request.
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.).
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.
Allows the Referrer-Policy header with the value to be set with a custom value.
When the SSL redirect is true, the host where the request is redirected to.
Header keys with associated values that would indicate a valid https request. Useful when using Nginx, e.g: "X-Forwarded-Proto": "https"
Redirect any request that is not using HTTPS
Set to true when you want the includeSubdomains be appended to the Strict-Transport-Security header.
Enable this policy by setting the max-age of the Strict-Transport-Security header. Setting to 0 disables HSTS.
Enterprise only. 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/
6 nested properties
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.
When true, all the inputs and evaluation results are printed in the console.
Advanced macros can be disabled in those policies not needing them for a faster evaluation.
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/
All the policies applied in the request context.
See: https://www.krakend.io/docs/enterprise/security-policies/
All the policies applied in the response context.
See: https://www.krakend.io/docs/enterprise/security-policies/
Enterprise only. Overrides metrics and traces declared by the OpenTelemetry service.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
4 nested properties
Enterprise only. Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
Enterprise only. Override exporter configuration for this endpoint
Overrides the global configuration for this endpoint.
See: https://www.krakend.io/docs/telemetry/opentelemetry-by-endpoint/
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/
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/
Apply automatic validations using a JSON Schema definition 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.
Enterprise only. The response schema validator 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/
2 nested properties
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/
In case the validation fails, the error definition containing body and status.
See: https://www.krakend.io/docs/enterprise/endpoints/response-schema-validator/
Enterprise only. Enables websocket communication.
17 nested properties
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'
Whether to send notification events to the backend or not when a user establishes a new Websockets connection.
Disables the OpenTelemetry metrics for the websocket connections.
Whether to send notification events to the backend or not when users disconnect from their Websockets connection.
When the value is set to true the communication is set one to one, and disables multiplexing. One client to KrakenD opens one connection to the backend. This mode of operation is sub-optimal in comparison to multiplexing.
Defines which input headers are allowed to pass to the backend. You don't need to declare the input_headers at the endpoint. Use * to pass all headers (not recommended, use explicit values instead). There are a few headers that won't be propagated regardless of your configuration, which are: Upgrade, Connection, Sec-Websocket-Extensions, Sec-Websocket-Version, and Sec-Websocket-Key.
[]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.
The maximum number of times you will allow KrakenD to retry reconnecting to a broken websockets server. When the maximum retries are reached, the gateway gives up the connection for good. Minimum value is 1 retry, or use <= 0 for unlimited retries.
Sets the maximum number of messages each end-user can have in the buffer waiting to be processed. As this is a per-end-user 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.
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.
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.
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.
Provides an error {'error':'reason here'} to the client when KrakenD was unable to send the message to the backend.
The list of subprotocols that the client can use to connect to the websocket.
[]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.
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.
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.
Defines the list of all headers allowed to reach the backend when passed.
By default, KrakenD won't pass any header from the client to the backend. This list is case-insensitive. You can declare headers in lowercase, uppercase, or mixed.
An entry ["Cookie"] forwards all cookies, and a single star element ["*"] as value forwards everything to the backend (it's safer to avoid this option), including cookies. See headers forwarding
[]Defines the exact list of quey strings parameters that are allowed to reach the backend. This list is case-sensitive.
By default, KrakenD won't pass any query string to the backend.
A single star element ["*"] as value forwards everything to the backend (it's safer to avoid this option)
See: https://www.krakend.io/docs/endpoints/parameter-forwarding/
[]The method supported by this endpoint. Create multiple endpoint entries if you need different methods.
The gateway can work with several content types, even allowing your clients to choose how to consume the content. See the supported encodings
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.
MCP functionality.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
The array of MCP servers available for linking to endpoints. Each object represents a different MCP server. The entry is only the definition of the server. You must create an endpoint that serves as the entrypoint to each server.
Enterprise only. Enables a Role-Based Access Control (RBAC) mechanism by reading the Authorization header of incoming requests.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
A list of objects defining each API Key.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The hashing function used to store the value of the key. When you use plain the API key is written as it will passed by the user. The rest of the hashes require you to save the API key after applying the desired function.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The header name or the query string name that contains the API key. Defaults to key when using the query_string strategy and to Authorization when using the header strategy. The identifier set here is used across all endpoints with API key authentication enabled, but they can override this entry individually.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The name of a header that will propagate to the backend containing the matching role. The backend receives no header when the string is empty, or the attribute is not declared. Otherwise, the backend receives the declared header name containing the first matching role of the user. The header value will be ANY when the endpoint does not require roles. For instance, if an API key has roles [A, B], and the endpoint demands roles [B, C], the backend will receive a header with the value B.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
A salt string for the desired hashing function. When provided, the API key is concatenated after the salt string and both hashed together.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
Specifies where to expect the user API key, whether inside a header or as part of the query string. The strategy set here is used across all endpoints with API key authentication enabled, but they can override this entry individually.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The API Gateway authorizes users that provide valid tokens according to your criteria, but at some point, you might want to change your mind and decide to revoke JWT tokens that are still valid.
The maximum Number of elements you want to keep in the bloom filter. Tens of millions work fine on machines with low resources.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The Probability of returning a false positive. E.g.,1e-7 for one false positive every 10 million different tokens. The values N and P determine the size of the resulting bloom filter to fulfill your expectations. E.g: 0.0000001
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The lifespan of the JWT you are generating in seconds. The value must match the expiration you are setting in the identity provider when creating the tokens.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
Either optimal (recommended) or default. The optimal consumes less CPU but has less entropy when generating the hash, although the loss is negligible.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The port number exposed on each KrakenD instance for the RPC service to interact with the bloomfilter. This port is allocated only to the clients (running KrakenDs).
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The list with all the claims in your JWT payload that need watching. These fields establish the criteria to revoke accesses in the future. The Revoker does not use this value, only the clients.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
A string used as an exchange API key to secure the communication between the Revoke Server and the KrakenD instances and to consume the REST API of the Revoker Server as well. E.g., a string generated with uuidgen.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
Maximum number of retries after a connection fails. When the value is less than zero it is changed automatically to zero.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
How many workers are used concurrently to execute an action (e.g., push a token) to all registered instances, allowing you to limit the amount of memory consumed by the server. For example, if you have 100 KrakenD servers and need to push 5MB of data each, you need to send 500MB in total. A max_workers=5 will consume a maximum of 5MB x 5 workers = 25MB of memory in a given instant. Defaults to the same number of CPUs available.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
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.
The address to the /instances endpoint in the Revoke Server.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
Enables global configurations for the HTTP client responsible of downloading and caching the JWK URLs for token validation and signing.
The cache duration in seconds for the JWK client retrieving the jwk_url. The endpoint must enable the cache option in order to use this second level cache.
Enterprise only. Generates postman documentation automatically through krakend postman export command.
See: https://www.krakend.io/docs/enterprise/developer/postman/
An introductory, optionally verbose, explanation supporting Markdown syntax. If you'd like to load an external markdown file, you can use flexible configuration, for instance "description": {{include "postman/intro.md" | toJson }}
See: https://www.krakend.io/docs/enterprise/developer/postman/
The folder definition where you will add endpoints
The name of the Postman collection you are generating.
See: https://www.krakend.io/docs/enterprise/developer/postman/
The version you assign to this Postman collection you are generating using semantic versioning.
See: https://www.krakend.io/docs/enterprise/developer/postman/
Declares rules and limits to be enforced.
The list of quota processors available for attachment. You can have multiple processors with different configurations.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. gRPC server integration
The paths to the different .pb files you want to load, or the paths to directories containing .pb files. All content is scanned in the order of the list, and after fetching all files it resolves the dependencies of their imports. The order you use here is not important to resolve imports, but it matters when there are conflicts (different files using the same namespace and package type).
Defines the gRPC server properties.
2 nested properties
Overrides OpenTelemetry settings for the gRPC server.
2 nested properties
Whether you want to disable all metrics happening in the gRPC server.
Whether you want to disable all traces happening in the gRPC server.
Defines one object per available gRPC service.
Enterprise only. Allows you to transform response headers declaratively.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to add. Every key under add is the header name, and the values are declared in an array with all those you want to set. If the header didn't exist previously, it is created with the values you passed. If the header existed, then the new values are appended.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The list of headers you want to delete. All headers listed will be missing in the response.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to rename. The key used under rename is the original header name, and the value the new header name. This operation is destructive, meaning that if you rename to a header name that already existed it will be replaced with the new header and value.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to replace. The key used under replace is the header name, and the value an array with all the header values you want to set. The replacement overwrites any other value that could exist in this header.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
Enterprise only. The GeoIP integration allows you load Maxmind's GeoIP2 City database (payment and free versions) and enrich all KrakenD calls to your backends with geo data.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
The path in the filesystem containing the database in GeoIP2 Binary (.mmdb) format. Relative to the working dir or absolute path.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
Enterprise only. The JWK aggregator plugin allows KrakenD to validate tokens issued by multiple Identity Providers.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
The list of all JWK URLs recognized as valid Identity Providers by the gateway.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
The port of the local server doing the aggregation. The port is only accessible within the gateway machine using localhost, and it's never exposed to the external network. Choose any port that is free in the system.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
When true, it stores the response of the Identity provider for the time specified in its Cache-Control header.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
Enterprise only. The global rate limit functionality enables a Redis database store to centralize all KrakenD node counters. Instead of having each KrakenD node count its hits, the counters are global and stored in the database.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
How many requests a client can make above the rate specified during a peak.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The URL to the Redis instance that stores the counters using the format host:port.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
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.
Number of allowed requests during the observed period.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
One of the preselected strategies to rate-limit users.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The field used to set a custom field for the tokenizer (e.g., extracting the token from a custom header other than Authorization or using a claim from a JWT other than the jti).
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
Enterprise only. Allows you to fetch and serve static content in two different use cases. When the plugin is used as an http server handler, the static content is for your end-users, giving them CSS, JS, images, or JSON files, to name a few examples. On the other side, when the plugin is used as an http client executor, the KrakenD endpoints use static content as if it were a backend.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. Allows you to declare additional URLs other than the ones defined under the endpoints configuration, used as aliases of existing endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
A map with the exact desired url and its mapping to an endpoint. If the endpoint has {placeholders} you need to write them, but the literal value {placeholders} is passed.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
A list of lists, containing the regular expression that defines the URL to be rewritten, and its endpoint destination. You can use the capturing groups with the syntax ${1}, ${2}, etc.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
Enterprise only. The Virtual Host plugin allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Enterprise only. Enables wildcard processing of requests without declaring all endpoint subresrouces.
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
The key of the map is the KrakenD endpoint that receives all the wildcard traffic. The value is an array with all the user paths that match this wildcard (you don't need to declare the subresources).
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/extending/http-server-plugins/
[]Enterprise only. The GeoIP integration allows you load Maxmind's GeoIP2 City database (payment and free versions) and enrich all KrakenD calls to your backends with geo data.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
1 nested properties
The path in the filesystem containing the database in GeoIP2 Binary (.mmdb) format. Relative to the working dir or absolute path.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
Enterprise only. The JWK aggregator plugin allows KrakenD to validate tokens issued by multiple Identity Providers.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
3 nested properties
The list of all JWK URLs recognized as valid Identity Providers by the gateway.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
The port of the local server doing the aggregation. The port is only accessible within the gateway machine using localhost, and it's never exposed to the external network. Choose any port that is free in the system.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
When true, it stores the response of the Identity provider for the time specified in its Cache-Control header.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
Enterprise only. The global rate limit functionality enables a Redis database store to centralize all KrakenD node counters. Instead of having each KrakenD node count its hits, the counters are global and stored in the database.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
6 nested properties
How many requests a client can make above the rate specified during a peak.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The URL to the Redis instance that stores the counters using the format host:port.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
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.
Number of allowed requests during the observed period.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
One of the preselected strategies to rate-limit users.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The field used to set a custom field for the tokenizer (e.g., extracting the token from a custom header other than Authorization or using a claim from a JWT other than the jti).
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
Enterprise only. Allows you to fetch and serve static content in two different use cases. When the plugin is used as an http server handler, the static content is for your end-users, giving them CSS, JS, images, or JSON files, to name a few examples. On the other side, when the plugin is used as an http client executor, the KrakenD endpoints use static content as if it were a backend.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
3 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. Allows you to declare additional URLs other than the ones defined under the endpoints configuration, used as aliases of existing endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
2 nested properties
A map with the exact desired url and its mapping to an endpoint. If the endpoint has {placeholders} you need to write them, but the literal value {placeholders} is passed.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
A list of lists, containing the regular expression that defines the URL to be rewritten, and its endpoint destination. You can use the capturing groups with the syntax ${1}, ${2}, etc.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
Enterprise only. The Virtual Host plugin allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
1 nested properties
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Enterprise only. Enables wildcard processing of requests without declaring all endpoint subresrouces.
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
1 nested properties
The key of the map is the KrakenD endpoint that receives all the wildcard traffic. The value is an array with all the user paths that match this wildcard (you don't need to declare the subresources).
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
Defines the Redis connection pools available to any functionality requiring Redis.
See: /docs/enterprise/throttling/global-rate-limit/
Defines all the clusters available to Redis functionality. The different components requiring Redis will access the pool based on its name
Defines all the connetion pools available to Redis functionality. The different components requiring Redis will access the pool based on its name
The optional router configuration allows you to set global flags that change the way KrakenD processes the requests at the router layer.
See: https://www.krakend.io/docs/service-settings/router-options/
The app_engine boolean trusts headers starting with X-AppEngine... for better integration with that PaaS.
See: https://www.krakend.io/docs/service-settings/router-options/
When true, enables the autogenerated OPTIONS endpoint for all the registered paths
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Decompresses any Gzipped content before sending it to the backend when the Content-Encoding has gzip in the first position. You can also set this value per endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
Stops registering access requests to KrakenD in the logs. You can still have a Backend Log if needed.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. All the output to the end user on the Enterprise Edition uses gzip when accepted by the client. Use this flag to remove gzip compression.
See: https://www.krakend.io/docs/service-settings/router-options/
Whether to checks if another method is allowed for the current route, if the current request can not be routed. If this is the case, the request is answered with Method Not Allowed and HTTP status code 405. If no other Method is allowed, the request is a 404.
See: https://www.krakend.io/docs/service-settings/router-options/
When true you don't have any exposed health endpoint. You can still use a TCP checker or build an endpoint yourself.
See: https://www.krakend.io/docs/service-settings/router-options/
Disables automatic validation of the url params looking for url encoded ones.
See: https://www.krakend.io/docs/service-settings/router-options/
If true, the router tries to fix the current request path, if no handle is registered for it
See: https://www.krakend.io/docs/service-settings/router-options/
Disables automatic redirection if the current route can't be matched but a handler for the path with (without) the trailing slash exists. Only works if disable_redirect_fixed_path is also set to true.
See: https://www.krakend.io/docs/service-settings/router-options/
Sets custom error bodies for 404 and 405 errors.
See: https://www.krakend.io/docs/service-settings/router-options/
2 nested properties
Write any JSON object structure you would like to return to users when they request an endpoint not known by KrakenD. 404 Not Found errors.
Write any JSON object structure you would like to return to users
When set to true, the client IP will be parsed from the default request's headers, or the custom ones (remote_ip_headers). If the IP has passed through a trusted proxy (e.g.: a proxy, load balancer, or a third party application) it will be extracted. If no IP can be fetched, it falls back to the IP obtained from the request's remote address. When declared you must configure trusted_proxies too.
See: https://www.krakend.io/docs/service-settings/router-options/
The path where you'd like to expose the health endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
Removes the version of KrakenD used in the X-KrakenD-version headers.
See: https://www.krakend.io/docs/service-settings/router-options/
Defines the set of paths that are removed from the logging.
See: https://www.krakend.io/docs/service-settings/router-options/
Sets the maxMemory param that is given to http.Request's Multipart Form method call.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Limits the maximum number of bytes a user can send to the gateway. 0 means no limit. You can also set this value per endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
List of headers used to obtain the client IP when forwarded_by_client_ip is set to true and the remote address is matched by at least one of the network origins of trusted_proxies.
See: https://www.krakend.io/docs/service-settings/router-options/
A parameter can be parsed from the URL even with extra slashes.
See: https://www.krakend.io/docs/service-settings/router-options/
When there is an error in the gateway (such as a timeout, a non-200 status code, etc.) it returns to the client the reason for the failure. The error is written in the body as is.
See: https://www.krakend.io/docs/service-settings/router-options/
List of network origins (IPv4 addresses, IPv4 CIDRs, IPv6 addresses or IPv6 CIDRs) from which to trust request's headers that contain alternative client IP when forwarded_by_client_ip is true. When declared you must configure forwarded_by_client_ip set to true, and optionally remote_ip_headers.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Allows you to fetch and serve static content by registering a static web server for a set of defined paths (the prefixes).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Whether to allow directory listings or not
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. The Virtual Host server allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
A map of all recognized virtual hosts where the key is the alias and the value the host name, including the port if it's not 443 or 80. The values declared here must match the content of the Host header passed by the client. The alias must be an alphanumeric string.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
1 nested properties
The key of this map must compile with the regexp a-z0-9_ and the host name is the string that matches the value sent by the user in the Host header.
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Send structured events in GELF format to your Graylog Cluster.
The address (including the port) of your Graylog cluster (or any other service that receives GELF inputs). E.g., myGraylogInstance:12201
Set to false (recommended) to use UDP, or true to use TCP. TCP performance is worst than UDP under heavy load.
Enables the extended logging capabilities.
The complete url of the influxdb including the port if different from defaults in http/https.
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.
The buffer size is a protection mechanism that allows you to temporarily store datapoints for later reporting when Influx is unavailable. If the buffer is 0, reported metrics that fail are discarded immediately. If the buffer is a positive number, KrakenD creates a buffer with the number of datapoints set. When the buffer is full because the Influx server keeps failing, newer datapoints replace older ones in the buffer.
Name of the InfluxDB database (Influx v1) or the bucket name (Influx v2).
Password to authenticate to InfluxDB. In Influx v2, you also need to add grant access with influx v1 auth.
Username to authenticate to InfluxDB.
Enables the extended logging capabilities.
What type of reporting level do you expect from the application? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
Specify the format of the application logs: default, logstash, or custom. The custom format needs an additional key "custom_format".
Enterprise only. You can write the access log pattern you would like to use. Add a newline \n at the end of the pattern. See the variables you can use.
Enterprise only. Enable a formatter for the access log. You can write your own pattern using the custom value, or you can use one of the predefined ones.
Enterprise only. When you use a custom access log format, the variable you are trying to print could be empty. For instance, you have added in the format %{header.Authorization} but the header is missing in the request. In this case, the printed value is what you configure here. If the string is set to an empty value, a dash - is printed.
Enables the Backend Log capabilities.
4 nested properties
Specify the custom format of the Backend Logs.
What type of reporting level do you want to set at the backends? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
When the variable does not resolve to any value, the string you want to write in the log. If the string is set to an empty value, a dash - is printed.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on.
Lets you write a custom logging pattern using variables, e.g: %{message}.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on. It's recommended to always add a prefix [INSIDE BRACKETS] to make use of predefined dashboards.
Set to true to send logs to stdout.
Set to true to send logs to syslog.
When using syslog, the facility tells KrakenD where to send the messages as set by the locals of the syslog standard.
Enables logstash when the extra_config "telemetry/logging" is also present.
Collects extended metrics to push to InfluxDB or expose them in the /__stats/ endpoint.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the backend layer. Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
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.
When true do not publish the /__stats/ endpoint. Metrics won't be accessible via the endpoint but still collected (and you can send them to Influx for instance).
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Change the listening address where the metrics endpoint is exposed.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the proxy layer (traffic against your backends). Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the router layer (activity in KrakenD endpoints). Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
The Moesif integration helps you understand and monetize API usage with a robust analytics and billing platform.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The Collector Application ID is used to send events, actions, users, and companies to Moesif's Collector API. Moesif provides it under the 'API Keys' section.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Defines the list of possible headers that can identify a user uniquely. When the header is Authorization, it automatically extracts the username if it contains an Authorization: Basic value with no additional configuration. If, on the other hand, you use tokens and pass an Authorization: Bearer, it will extract the user ID from the JWT claim defined under user_id_jwt_claim. If there are multiple headers in the list, all of them are tested in the given order, and the first existing header in the list is used to extract the user ID (successfully or not).
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Number of events you will send on every batch reporting asynchronously to Moesif. For high throughput you will need to increase this value.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Set to true when configuring Moesif for the first time while in development, to see the activity in the logs. Set to false in production.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Sends the number of events you can hold in-memory to send them asynchronously to Moesif. If the throughput of your API generates more events than the size of the queue, the exceeding events will be discarded and not reported.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
It sets which strategy you want to use to identify the company. Identifying the company helps you efficiently govern your API. Choose the system you wish to apply (declare only one property). The claim value you access must be of type string. You can access nested structured using the dot . separator. When using dots, literals with an exact match containing the dot are checked first.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
3 nested properties
The company is identified using a header. Provide the header name.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The company is stored in a claim inside the JWT. The claim must return a string.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The company is always passed inside a query string when calling any URL. Provide the query string name.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Send the body of all endpoints and requests to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
A free-form object that allows you to push custom metadata along with events. The custom metadata appears in Moesif under a key krakend, you can use nesting if needed.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of fields in the request body that you want to mask before sending them to Moesif. You can set log_body to false to prevent any body being sent.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of request headers that you want to mask their values before sending them to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of fields in the response body that you want to mask before sending them to Moesif. You can set log_body to false to prevent any body being sent.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of response headers that you want to mask their values before sending them to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Defines an expression expressed as Security Policy that avoids reporting to Moesif when the result of the evaluation is true.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Specifies how often a background thread runs to send events to Moesif. Value in seconds.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
When using JWT tokens, it defines which claim contains the user ID. The claim value you access must be of type string. You can access nested structured using the dot . separator. When using dots, literals with an exact match containing the dot are checked first.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The New Relic integration lets you push KrakenD metrics and distributed traces to your New Relic dashboard. It uses internally the official New Relic SDK and brings its features to your APM dashboard.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
The API key provided by New Relic to push data into your account.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Set to true when configuring New Relic for the first time while in development, to see the activity in the logs. Set to false in production.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Defines an explicit list of headers sent during the client request that will be reported to NewRelic, in addition to the default headers NewRelic sets. Setting the ["*"] value will send all headers sent by the client to NewRelic. Whether you declare this setting or not, you will usually receive from the NewRelic SDK the Accept, Content-Type, User-Agent, and Referer headers.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Enables the extended logging capabilities.
The exporter(s) you would like to enable. See each exporter configuration in its own section.
9 nested properties
Datadog is a monitoring and security platform for developers, IT operations teams and business in the cloud.
7 nested properties
Specifies whether to emit count_per_bucket metrics.
A set of tags (key/value) that will automatically be applied to all exported spans.
The namespace to which metric keys are appended.
Service specifies the service name used for tracing
Specifies the host[:port] address for DogStatsD. To enable ingestion using Unix Domain Socket (UDS) mount your UDS path and reference it in the stats_address using a path like unix:///var/run/datadog/dsd.socket.
Specifies a set of global tags to attach to each metric.
Specifies the host[:port] address of the Datadog Trace Agent.
Exports data to InfluxDB: A time series database designed to handle high write and query loads.
5 nested properties
The URL (including port) where your InfluxDB is installed.
The database name
The password to access the database
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.
The influxdb username to access the database
Submit spans to a Jaeger Collector (HTTP) with endpoint or to a Jaeger Agent (UDP) with agent_endpoint.
4 nested properties
The address where the Jaeger Agent is (Thrift over UDP), e.g., jaeger:6831
Total number of traces to buffer in memory
The full URL including port indicating where your Jaeger Collector is (Thrift over HTTP/S), e.g., <http://jaeger:14268/api/traces>
The service name registered in Jaeger
Opencensus can export data to the system logger as another exporter. Recommended to use telemetry/logging instead.
2 nested properties
Whether to log the spans or not
Whether to log the statistics or not
Exporting metrics, logs, and events to the OpenCensus Agent.
6 nested properties
The address of your Azure Monitor collector.
An identifier of your service, e.g, krakend.
Whether to send data compressed or not.
List of keys and values for the headers sent. Keys and values must be of type string.
Whether the connection can be established in plain (insecure) or not.
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.
Prometheus is an open-source systems monitoring and alerting toolkit.
6 nested properties
Port on which the Prometheus exporter should listen
Sets the domain the metric belongs to.
Whether to send the host as a metric or not.
Whether to send the HTTP method as a metric or not.
Whether to send the path as a metric or not.
Whether to send the status code as a metric or not.
Export metrics and traces to Google Cloud
3 nested properties
A map object. Enter here any label that will be assigned by default to the reported metric so you can filter later on Stack Driver.
The identifier of your Google Cloud project. The project_id is not the project name. You can omit this value from the configuration if you have an application credential file for Google.
A prefix that you can add to all your metrics for better organization.
AWS X-Ray is a service offered by Amazon that provides an end-to-end view of requests as they travel through your application, and shows a map of your application's underlying components.
5 nested properties
The AWS geographical region, e.g, us-east-1.
The version of the AWS X-Ray service to use.
Your access key ID provided by Amazon. Needed when use_env is unset or set to false.
Your secret access key provided by Amazon. Needed when use_env is unset or set to false.
When true the AWS credentials (access_key_id and secret_access_key) are taken from environment vars. Don't specify them then.
Export telemetry data to a Zipkin collector
2 nested properties
The URL (including port and path) where your Zipkin is accepting the spans, e.g., <http://zipkin:9411/api/v2/spans>
The service name registered in Zipkin.
Lets you specify what data you want to export. All layers are enabled by default unless you declare this section.
3 nested properties
Reports the activity between KrakenD and your services
Reports the activity at the beginning of the proxy layer. It gives a more detailed view of the internals of the pipe between end-users and KrakenD, having into account merging of different backends.
Reports the activity between end-users and KrakenD
The number of seconds passing between reports. If duration is less than or equal to zero, it enables the default behavior of each exporter.
A number between 0 (no requests at all) and 100 (all requests) representing the percentage of sampled requests you want to send to the exporter. Sampling the 100% of the requests is generally discouraged when the relationship between traffic and dedicated resources is sparse.
Enables metrics and traces using OpenTelemetry.
The places where you will send telemetry data. You can declare multiple exporters even when they are of the same type. For instance, when you have a self-hosted Grafana and would like to migrate to its cloud version and check the double reporting during the transition. There are two families of exporters: otlp or prometheus.
2 nested properties
The list of OTLP exporters you want to use. Set at least one object to push metrics and traces to an external collector using OTLP.
Set here at least the settings for one Prometheus exporter. Each exporter will start a local port that offers metrics to be pulled from KrakenD.
The environment you are deploying, this can be useful for deployment tracking. The string can have any value that makes sense to you to identify the running environment.
Use an histogram bucket configuration different from the defaults to define the detail of histogram metrics (decrease or increase their size). You don't need to set this attribute unless you want full control of the histogram definition.
2 nested properties
The size of the buckets in bytes you want to use for the histograms.
[
128,
256,
512,
1024,
4096,
8192,
16384,
32768,
65536,
262144,
524288,
1048576,
4194304,
16777216,
67108864
]The duration of buckets in seconds you want to use for the histograms.
[
0.01,
0.02,
0.05,
0.075,
0.1,
0.125,
0.15,
0.175,
0.2,
0.25,
0.3,
0.35,
0.5,
0.75,
1.0,
1.5,
2.0,
3.5,
5.0,
10.0
]A request and response flow passes through three different layers. This attribute lets you specify what data you want to export in each layer. All layers are enabled by default unless you declare this section.
3 nested properties
Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
2 nested properties
Reports the activity between end-users and KrakenD
8 nested properties
Whether you want to disable all metrics happening in the global layer or not.
Whether you want to ignore previous propagation headers to KrakenD. When the flag is set to true, spans from a previous layer will never be linked to the KrakenD trace.
Whether you want to disable all traces happening in the global layer or not.
Static attributes you want to pass for metrics.
Whether you want to send all headers that the consumer passed in the request or not.
A list of headers you want to skip when reporting the headers from the request. This is useful to avoid reporting sensitive data.
The semantic convention naming you want to use. The default is an empty string which uses the original naming convention prior to 1.27. For the semantic convention of 1.27 and higher, use 1.27
Static attributes you want to pass for traces.
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
6 nested properties
Whether you want to disable all metrics happening in the proxy layer or not.
Whether you want to disable all traces happening in the proxy layer or not.
Static attributes you want to pass for metrics.
Whether you want to report all headers that passed from the request to the proxy layer (input_headers policy in the endpoint plus KrakenD's headers).
A list of headers you want to skip when reporting headers passed to the proxy layer. This is useful to avoid reporting sensitive data.
Static attributes you want to pass for traces.
How often you want to report and flush the metrics in seconds. This setting is only used by otlp exporters.
A friendly name identifying metrics reported by this installation. When unset, it uses the name attribute in the root level of the configuration.
The version you are deploying, this can be useful for deployment tracking.
The paths you don't want to report. Use the literal value used in the endpoint definition, including any {placeholders}. In the global layer, this attribute works only on metrics, because traces are initiated before there is an endpoint to match against. If you do not want any path skipped, just add an array with an empty string [""].
[
"/__health",
"/__debug/",
"/__echo/",
"/__stats/"
]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.
Enables the security layer needed to use OpenTelemetry through the Internet, like pushing data to a SaaS provider.
See: https://www.krakend.io/docs/telemetry/opentelemetry-security/
The list of OTLP exporters that require authentication. Set at least one object to push metrics and traces to an external collector using OTLP.
See: https://www.krakend.io/docs/telemetry/opentelemetry-security/
MCP functionality.
See: https://www.krakend.io/docs/enterprise/ai-gateway/mcp-server/
1 nested properties
The array of MCP servers available for linking to endpoints. Each object represents a different MCP server. The entry is only the definition of the server. You must create an endpoint that serves as the entrypoint to each server.
Enterprise only. Enables a Role-Based Access Control (RBAC) mechanism by reading the Authorization header of incoming requests.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
6 nested properties
A list of objects defining each API Key.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The hashing function used to store the value of the key. When you use plain the API key is written as it will passed by the user. The rest of the hashes require you to save the API key after applying the desired function.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The header name or the query string name that contains the API key. Defaults to key when using the query_string strategy and to Authorization when using the header strategy. The identifier set here is used across all endpoints with API key authentication enabled, but they can override this entry individually.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
The name of a header that will propagate to the backend containing the matching role. The backend receives no header when the string is empty, or the attribute is not declared. Otherwise, the backend receives the declared header name containing the first matching role of the user. The header value will be ANY when the endpoint does not require roles. For instance, if an API key has roles [A, B], and the endpoint demands roles [B, C], the backend will receive a header with the value B.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
A salt string for the desired hashing function. When provided, the API key is concatenated after the salt string and both hashed together.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
Specifies where to expect the user API key, whether inside a header or as part of the query string. The strategy set here is used across all endpoints with API key authentication enabled, but they can override this entry individually.
See: https://www.krakend.io/docs/enterprise/authentication/api-keys/
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/
2 nested properties
Absolute Path to the htpasswd filename (recommended) or relative ./ to the workdir (less secure).
See: https://www.krakend.io/docs/enterprise/authentication/basic-authentication/
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/
The API Gateway authorizes users that provide valid tokens according to your criteria, but at some point, you might want to change your mind and decide to revoke JWT tokens that are still valid.
11 nested properties
The maximum Number of elements you want to keep in the bloom filter. Tens of millions work fine on machines with low resources.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The Probability of returning a false positive. E.g.,1e-7 for one false positive every 10 million different tokens. The values N and P determine the size of the resulting bloom filter to fulfill your expectations. E.g: 0.0000001
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The lifespan of the JWT you are generating in seconds. The value must match the expiration you are setting in the identity provider when creating the tokens.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
Either optimal (recommended) or default. The optimal consumes less CPU but has less entropy when generating the hash, although the loss is negligible.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The port number exposed on each KrakenD instance for the RPC service to interact with the bloomfilter. This port is allocated only to the clients (running KrakenDs).
See: https://www.krakend.io/docs/authorization/revoking-tokens/
The list with all the claims in your JWT payload that need watching. These fields establish the criteria to revoke accesses in the future. The Revoker does not use this value, only the clients.
See: https://www.krakend.io/docs/authorization/revoking-tokens/
A string used as an exchange API key to secure the communication between the Revoke Server and the KrakenD instances and to consume the REST API of the Revoker Server as well. E.g., a string generated with uuidgen.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
Maximum number of retries after a connection fails. When the value is less than zero it is changed automatically to zero.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
How many workers are used concurrently to execute an action (e.g., push a token) to all registered instances, allowing you to limit the amount of memory consumed by the server. For example, if you have 100 KrakenD servers and need to push 5MB of data each, you need to send 500MB in total. A max_workers=5 will consume a maximum of 5MB x 5 workers = 25MB of memory in a given instant. Defaults to the same number of CPUs available.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
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.
The address to the /instances endpoint in the Revoke Server.
See: https://www.krakend.io/docs/enterprise/authentication/revoke-server/
Enables global configurations for the HTTP client responsible of downloading and caching the JWK URLs for token validation and signing.
1 nested properties
The cache duration in seconds for the JWK client retrieving the jwk_url. The endpoint must enable the cache option in order to use this second level cache.
Enterprise only. Generates OpenAPI documentation automatically through krakend openapi export command.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
28 nested properties
An introductory, optionally verbose, explanation supporting CommonMark 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/
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/
A starting path that is appended to any endpoint.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The JSON Schemas you can reuse inside endpoint definitions using ref. You can either pass the JSON Schema object, or a bas64 string.
Email where users of your API can write to.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact name.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Contact URL that users of your API can read.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the cookie used under components securitySchemes.
Allows you to add custom security schemes under components/securitySchemes in the generated OpenAPI spec. This is useful when you want to define your own security schemes, different from the built-in ones (e.g., jwt, apikey, cookie, etc.). When the property is in the service level you must declare the schema (e.g., "OAuth2Security":{...}), and when it is in the endpoint you should only write the object name with not properties inside, e.g, {"OAuth2Security":{}.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
By default, KrakenD adds a 500 and a 200 response definition to each endpoint. Set this property to true if you want to avoid this behavior.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the headers allowed in the endpoint. Make sure to include the same headers in the endpoint's input_headers.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The hostname where you will publish your API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
When generating an OpenAPI spec, the name of the JWT key used under components securitySchemes.
The license name (e.g.: Apache License)
See: https://www.krakend.io/docs/enterprise/developer/openapi/
The URL where the license is hosted
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Sets a detailed description for the URL parameters (e.g.: /foo/{param}) required in the endpoint. Make sure to include to write the param exactly as in the endpoint definition.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed 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/
Describes the payload 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.This property is an array because you can document requests with multiple content types.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The list of schemes supported by the API, e.g. http or https
See: https://www.krakend.io/docs/enterprise/developer/openapi/
[
"http"
]The list of servers where the API is hosted. The server URL can be a relative path, e.g., /v1 or an absolute path. The URL might contain {variables}, although these are only recognized by OpenAPI and to KrakenD they are just literal strings because it does not use them.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
A short summary for the endpoint. Use the description field for the longest explanation.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
Sets a detailed description for the tags classifiying endpoints when generating the OpenAPI spec.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
The URL to the terms of service for using this API.
See: https://www.krakend.io/docs/enterprise/developer/openapi/
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/
Enterprise only. Generates postman documentation automatically through krakend postman export command.
See: https://www.krakend.io/docs/enterprise/developer/postman/
4 nested properties
An introductory, optionally verbose, explanation supporting Markdown syntax. If you'd like to load an external markdown file, you can use flexible configuration, for instance "description": {{include "postman/intro.md" | toJson }}
See: https://www.krakend.io/docs/enterprise/developer/postman/
The folder definition where you will add endpoints
The name of the Postman collection you are generating.
See: https://www.krakend.io/docs/enterprise/developer/postman/
The version you assign to this Postman collection you are generating using semantic versioning.
See: https://www.krakend.io/docs/enterprise/developer/postman/
Declares rules and limits to be enforced.
1 nested properties
The list of quota processors available for attachment. You can have multiple processors with different configurations.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. Attach a quota to the endpoint, backend, or service. Needs a governance/processor namespace.
See: https://www.krakend.io/docs/enterprise/governance/quota/
7 nested properties
Name of the quota you want to reuse, written exactly as declared under the processors list.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Header used to determine the tier. Use tier_value and tier_value_as on each tier to determine how to match the value.
See: https://www.krakend.io/docs/enterprise/governance/quota/
List of tiers to match against the request. The first tier that matches will be used to determine the quota to consume.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When set to true, the quota headers X-Quota-Limit, X-Quota-Remaining, and Retry-After will not be added to the response. This is useful when you want to hide the quota information from the client.
See: https://www.krakend.io/docs/enterprise/governance/quota/
When a tier cannot be infered from the request, whether to allow the request to continue or not. In case a request does not match any of the tiers, the request will be rejected with a 400 error unless you set this to true.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Instead of incrementing the quota counter by one unit, use the value provided in a field or header with its dynamic value. For instance, an LLM can return how many tokens it consumed, and you can use that value to increment the quota counter. The value must be a parseable number, and the field or header must be present in the backend response. The weight_key is only used in the endpoint and backend scopes, and it is ignored in the service level.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Where to find the key containing the counter value to increment. Use body for any type of encoding different than no-op and header for no-op.
See: https://www.krakend.io/docs/enterprise/governance/quota/
Enterprise only. gRPC server integration
2 nested properties
The paths to the different .pb files you want to load, or the paths to directories containing .pb files. All content is scanned in the order of the list, and after fetching all files it resolves the dependencies of their imports. The order you use here is not important to resolve imports, but it matters when there are conflicts (different files using the same namespace and package type).
Defines the gRPC server properties.
2 nested properties
Overrides OpenTelemetry settings for the gRPC server.
Defines one object per available gRPC service.
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.
7 nested properties
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.
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).
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.
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()).
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()).
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.
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.
Enterprise only. Extracts fields from the incoming request body and promotes them to request headers or query strings.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
1 nested properties
A list of extraction operations to apply. Each operation extracts a value from the request body and writes it to a header or query string parameter. Operations are evaluated in sequential order.
See: https://www.krakend.io/docs/enterprise/endpoints/request-body-extractor/
Enterprise only. Allows you to transform response headers declaratively.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
4 nested properties
The headers you want to add. Every key under add is the header name, and the values are declared in an array with all those you want to set. If the header didn't exist previously, it is created with the values you passed. If the header existed, then the new values are appended.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The list of headers you want to delete. All headers listed will be missing in the response.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to rename. The key used under rename is the original header name, and the value the new header name. This operation is destructive, meaning that if you rename to a header name that already existed it will be replaced with the new header and value.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
The headers you want to replace. The key used under replace is the header name, and the value an array with all the header values you want to set. The replacement overwrites any other value that could exist in this header.
See: https://www.krakend.io/docs/enterprise/service-settings/response-headers-modifier/
9 nested properties
An array with the names of plugins to load. The names are defined inside your plugin.
See: https://www.krakend.io/docs/extending/http-server-plugins/
[]Enterprise only. The GeoIP integration allows you load Maxmind's GeoIP2 City database (payment and free versions) and enrich all KrakenD calls to your backends with geo data.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
1 nested properties
The path in the filesystem containing the database in GeoIP2 Binary (.mmdb) format. Relative to the working dir or absolute path.
See: https://www.krakend.io/docs/enterprise/endpoints/geoip/
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/
4 nested properties
The CIDR blocks (list of IPs) you want to allow or deny.
See: https://www.krakend.io/docs/enterprise/throttling/ipfilter/
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/
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/
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/
Enterprise only. The JWK aggregator plugin allows KrakenD to validate tokens issued by multiple Identity Providers.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
3 nested properties
The list of all JWK URLs recognized as valid Identity Providers by the gateway.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
The port of the local server doing the aggregation. The port is only accessible within the gateway machine using localhost, and it's never exposed to the external network. Choose any port that is free in the system.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
When true, it stores the response of the Identity provider for the time specified in its Cache-Control header.
See: https://www.krakend.io/docs/enterprise/authentication/multiple-identity-providers/
Enterprise only. The global rate limit functionality enables a Redis database store to centralize all KrakenD node counters. Instead of having each KrakenD node count its hits, the counters are global and stored in the database.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
6 nested properties
How many requests a client can make above the rate specified during a peak.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The URL to the Redis instance that stores the counters using the format host:port.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
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.
Number of allowed requests during the observed period.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
One of the preselected strategies to rate-limit users.
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
The field used to set a custom field for the tokenizer (e.g., extracting the token from a custom header other than Authorization or using a claim from a JWT other than the jti).
See: https://www.krakend.io/docs/enterprise/endpoints/global-rate-limit/
Enterprise only. Allows you to fetch and serve static content in two different use cases. When the plugin is used as an http server handler, the static content is for your end-users, giving them CSS, JS, images, or JSON files, to name a few examples. On the other side, when the plugin is used as an http client executor, the KrakenD endpoints use static content as if it were a backend.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
3 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. Allows you to declare additional URLs other than the ones defined under the endpoints configuration, used as aliases of existing endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
2 nested properties
A map with the exact desired url and its mapping to an endpoint. If the endpoint has {placeholders} you need to write them, but the literal value {placeholders} is passed.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
A list of lists, containing the regular expression that defines the URL to be rewritten, and its endpoint destination. You can use the capturing groups with the syntax ${1}, ${2}, etc.
See: https://www.krakend.io/docs/enterprise/endpoints/url-rewrite/
Enterprise only. The Virtual Host plugin allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
1 nested properties
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Enterprise only. Enables wildcard processing of requests without declaring all endpoint subresrouces.
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
1 nested properties
The key of the map is the KrakenD endpoint that receives all the wildcard traffic. The value is an array with all the user paths that match this wildcard (you don't need to declare the subresources).
See: https://www.krakend.io/docs/enterprise/endpoints/wildcard/
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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.
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.
These are the number of routines that search for and remove outdated rate limit counters. The more routine(s) you add, the faster the memory optimization is completed, but the more CPU it will consume. Generally speaking, a single thread is more than enough because the delete operation is very fast, even with a large number of counters. This is an advanced micro-optimization setting that you should use with caution.
Defines the maximum number of tokens a bucket can hold, 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.
Number of tokens you add to the 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.
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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.
All rate limit counters are stored in memory in groups (shards). All counters in the same shard share a mutex (which controls that one counter is modified at a time), and this helps with contention. Having, for instance, 2048 shards (default) and 1M users connected concurrently (same instant) means that each user will need to coordinate writes in their counter with an average of under 500 other users (1M/2048=489). Lowering the shards might increase contention and latency but free additional memory. This is an advanced micro-optimization setting that should be used with caution.
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.
Enterprise only. Redis-backed service ratelimit
10 nested properties
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Defines the maximum number of tokens a bucket can hold, 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/enterprise/throttling/global-rate-limit/
Number of tokens you add to the 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/enterprise/throttling/global-rate-limit/
The connection pool name or cluster name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
The connection pool name that is used by this ratelimit. The value must match what you configured in the Redis Connection Pool
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.
Available when using client_max_rate and you have set a strategy equal to header or param. It makes no sense in other contexts. For header it is the header name containing the user identification (e.g., Authorization on tokens, or X-Original-Forwarded-For for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For param it is the name of the placeholder used in the endpoint, like id_user for an endpoint /user/{id_user}.
See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/
Sets the maximum number of requests all users can do in the given time frame. Internally uses the 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/enterprise/throttling/global-rate-limit/
Whether you want to allow a request to continue when the Redis connection is failing or not. The default behavior blocks the request if Redis is not responding correctly
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/enterprise/throttling/global-rate-limit/
Enterprise only. Apply ratelimit based on tier match.
2 nested properties
The header name containing the tier name. The string you provide is case-insensitive. If you need to take the value from a place that is not a header (a token, an API key), you must use propagate functions in the components that convert values to internal headers.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
The list of all tier definitions and limits for each. Each item in the list is a tier object.
See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/
Defines the Redis connection pools available to any functionality requiring Redis.
See: /docs/enterprise/throttling/global-rate-limit/
2 nested properties
Defines all the clusters available to Redis functionality. The different components requiring Redis will access the pool based on its name
Defines all the connetion pools available to Redis functionality. The different components requiring Redis will access the pool based on its name
The optional router configuration allows you to set global flags that change the way KrakenD processes the requests at the router layer.
See: https://www.krakend.io/docs/service-settings/router-options/
21 nested properties
The app_engine boolean trusts headers starting with X-AppEngine... for better integration with that PaaS.
See: https://www.krakend.io/docs/service-settings/router-options/
When true, enables the autogenerated OPTIONS endpoint for all the registered paths
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Decompresses any Gzipped content before sending it to the backend when the Content-Encoding has gzip in the first position. You can also set this value per endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
Stops registering access requests to KrakenD in the logs. You can still have a Backend Log if needed.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. All the output to the end user on the Enterprise Edition uses gzip when accepted by the client. Use this flag to remove gzip compression.
See: https://www.krakend.io/docs/service-settings/router-options/
Whether to checks if another method is allowed for the current route, if the current request can not be routed. If this is the case, the request is answered with Method Not Allowed and HTTP status code 405. If no other Method is allowed, the request is a 404.
See: https://www.krakend.io/docs/service-settings/router-options/
When true you don't have any exposed health endpoint. You can still use a TCP checker or build an endpoint yourself.
See: https://www.krakend.io/docs/service-settings/router-options/
Disables automatic validation of the url params looking for url encoded ones.
See: https://www.krakend.io/docs/service-settings/router-options/
If true, the router tries to fix the current request path, if no handle is registered for it
See: https://www.krakend.io/docs/service-settings/router-options/
Disables automatic redirection if the current route can't be matched but a handler for the path with (without) the trailing slash exists. Only works if disable_redirect_fixed_path is also set to true.
See: https://www.krakend.io/docs/service-settings/router-options/
Sets custom error bodies for 404 and 405 errors.
See: https://www.krakend.io/docs/service-settings/router-options/
2 nested properties
Write any JSON object structure you would like to return to users when they request an endpoint not known by KrakenD. 404 Not Found errors.
Write any JSON object structure you would like to return to users
When set to true, the client IP will be parsed from the default request's headers, or the custom ones (remote_ip_headers). If the IP has passed through a trusted proxy (e.g.: a proxy, load balancer, or a third party application) it will be extracted. If no IP can be fetched, it falls back to the IP obtained from the request's remote address. When declared you must configure trusted_proxies too.
See: https://www.krakend.io/docs/service-settings/router-options/
The path where you'd like to expose the health endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
Removes the version of KrakenD used in the X-KrakenD-version headers.
See: https://www.krakend.io/docs/service-settings/router-options/
Defines the set of paths that are removed from the logging.
See: https://www.krakend.io/docs/service-settings/router-options/
Sets the maxMemory param that is given to http.Request's Multipart Form method call.
See: https://www.krakend.io/docs/service-settings/router-options/
Enterprise only. Limits the maximum number of bytes a user can send to the gateway. 0 means no limit. You can also set this value per endpoint.
See: https://www.krakend.io/docs/service-settings/router-options/
List of headers used to obtain the client IP when forwarded_by_client_ip is set to true and the remote address is matched by at least one of the network origins of trusted_proxies.
See: https://www.krakend.io/docs/service-settings/router-options/
A parameter can be parsed from the URL even with extra slashes.
See: https://www.krakend.io/docs/service-settings/router-options/
When there is an error in the gateway (such as a timeout, a non-200 status code, etc.) it returns to the client the reason for the failure. The error is written in the body as is.
See: https://www.krakend.io/docs/service-settings/router-options/
List of network origins (IPv4 addresses, IPv4 CIDRs, IPv6 addresses or IPv6 CIDRs) from which to trust request's headers that contain alternative client IP when forwarded_by_client_ip is true. When declared you must configure forwarded_by_client_ip set to true, and optionally remote_ip_headers.
See: https://www.krakend.io/docs/service-settings/router-options/
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.
5 nested properties
An array with EXACT MATCHES of trusted user agents that can connect.
[]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.
An array with EXACT MATCHES of undesired bots, to reject immediately.
[]Whether to consider an empty user-agent a bot (and reject it) or not.
An array with all the regular expressions that define bots. Matching bots are rejected.
[]When KrakenD endpoints are consumed from a browser, you might need to enable the Cross-Origin Resource Sharing (CORS) module as browsers restrict cross-origin HTTP requests initiated from scripts.
{
"allow_methods": [
"POST",
"GET"
],
"allow_origins": [
"http://foobar.com"
],
"max_age": "12h"
}7 nested properties
An array with all the origins allowed, examples of values are https://example.com, or * (any origin).
When requests can include user credentials like cookies, HTTP authentication or client side SSL certificates
[]The array of all HTTP methods accepted, in uppercase.
Show debugging information in the logger, to be used only during development.
Headers that are safe to expose to the API of a CORS API specification-
[]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.
Security through HTTP headers, including HSTS, HPKP, MIME-Sniffing prevention, Clickjacking protection, and others.
17 nested properties
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.
[]Treat the allowed hosts list as regular expressions.
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
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.
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.
Force a STS Header even if using plain HTTP.
Set to true to enable clickjacking protection, together with custom_frame_options_value.
A set of header keys that may hold a proxied hostname value for the request.
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.).
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.
Allows the Referrer-Policy header with the value to be set with a custom value.
When the SSL redirect is true, the host where the request is redirected to.
Header keys with associated values that would indicate a valid https request. Useful when using Nginx, e.g: "X-Forwarded-Proto": "https"
Redirect any request that is not using HTTPS
Set to true when you want the includeSubdomains be appended to the Strict-Transport-Security header.
Enable this policy by setting the max-age of the Strict-Transport-Security header. Setting to 0 disables HSTS.
Enterprise only. Allows you to fetch and serve static content by registering a static web server for a set of defined paths (the prefixes).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
4 nested properties
The folder in the filesystem containing the static files. Relative to the working dir where KrakenD config is (e.g.: ./assets) or absolute (e.g.: /var/www/assets).
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
This is the beginning (prefix) of all URLs that are resolved using this plugin. All matching URLs won't be passed to the router, meaning that they are not considered endpoints. Make sure you are not overwriting valid endpoints. When the prefix is /, then all traffic is served as static and you must declare a prefix under skip (e.g.: /api) to match endpoints.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Whether to allow directory listings or not
An array with all the prefix URLs that despite they could match with the prefix, you don't want to treat them as static content and pass them to the router.
See: https://www.krakend.io/docs/enterprise/endpoints/serve-static-content/
Enterprise only. The Virtual Host server allows you to run different configurations of KrakenD endpoints based on the host accessing the server.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
2 nested properties
A map of all recognized virtual hosts where the key is the alias and the value the host name, including the port if it's not 443 or 80. The values declared here must match the content of the Host header passed by the client. The alias must be an alphanumeric string.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
1 nested properties
The key of this map must compile with the regexp a-z0-9_ and the host name is the string that matches the value sent by the user in the Host header.
All recognized virtual hosts by KrakenD must be listed here. The values declared here must match the content of the Host header when passed by the client.
See: https://www.krakend.io/docs/enterprise/service-settings/virtual-hosts/
Send structured events in GELF format to your Graylog Cluster.
2 nested properties
The address (including the port) of your Graylog cluster (or any other service that receives GELF inputs). E.g., myGraylogInstance:12201
Set to false (recommended) to use UDP, or true to use TCP. TCP performance is worst than UDP under heavy load.
Enables the extended logging capabilities.
6 nested properties
The complete url of the influxdb including the port if different from defaults in http/https.
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.
The buffer size is a protection mechanism that allows you to temporarily store datapoints for later reporting when Influx is unavailable. If the buffer is 0, reported metrics that fail are discarded immediately. If the buffer is a positive number, KrakenD creates a buffer with the number of datapoints set. When the buffer is full because the Influx server keeps failing, newer datapoints replace older ones in the buffer.
Name of the InfluxDB database (Influx v1) or the bucket name (Influx v2).
Password to authenticate to InfluxDB. In Influx v2, you also need to add grant access with influx v1 auth.
Username to authenticate to InfluxDB.
Enables the extended logging capabilities.
11 nested properties
What type of reporting level do you expect from the application? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
Specify the format of the application logs: default, logstash, or custom. The custom format needs an additional key "custom_format".
Enterprise only. You can write the access log pattern you would like to use. Add a newline \n at the end of the pattern. See the variables you can use.
Enterprise only. Enable a formatter for the access log. You can write your own pattern using the custom value, or you can use one of the predefined ones.
Enterprise only. When you use a custom access log format, the variable you are trying to print could be empty. For instance, you have added in the format %{header.Authorization} but the header is missing in the request. In this case, the printed value is what you configure here. If the string is set to an empty value, a dash - is printed.
Enables the Backend Log capabilities.
4 nested properties
Specify the custom format of the Backend Logs.
What type of reporting level do you want to set at the backends? The options below go from more verbose to least. Use the DEBUG level in the development stages but not in production. Some components can add extra verbosity while in DEBUG mode and send multiline content, which is not always suitable for automated log parsing.
When the variable does not resolve to any value, the string you want to write in the log. If the string is set to an empty value, a dash - is printed.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on.
Lets you write a custom logging pattern using variables, e.g: %{message}.
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on. It's recommended to always add a prefix [INSIDE BRACKETS] to make use of predefined dashboards.
Set to true to send logs to stdout.
Set to true to send logs to syslog.
When using syslog, the facility tells KrakenD where to send the messages as set by the locals of the syslog standard.
Enables logstash when the extra_config "telemetry/logging" is also present.
1 nested properties
Collects extended metrics to push to InfluxDB or expose them in the /__stats/ endpoint.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
6 nested properties
Skip any metrics happening in the backend layer. Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
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.
When true do not publish the /__stats/ endpoint. Metrics won't be accessible via the endpoint but still collected (and you can send them to Influx for instance).
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Change the listening address where the metrics endpoint is exposed.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the proxy layer (traffic against your backends). Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
Skip any metrics happening in the router layer (activity in KrakenD endpoints). Disabling layers saves memory consumption but reduces visibility.
See: https://www.krakend.io/docs/telemetry/extended-metrics/
The Moesif integration helps you understand and monetize API usage with a robust analytics and billing platform.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
15 nested properties
The Collector Application ID is used to send events, actions, users, and companies to Moesif's Collector API. Moesif provides it under the 'API Keys' section.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Defines the list of possible headers that can identify a user uniquely. When the header is Authorization, it automatically extracts the username if it contains an Authorization: Basic value with no additional configuration. If, on the other hand, you use tokens and pass an Authorization: Bearer, it will extract the user ID from the JWT claim defined under user_id_jwt_claim. If there are multiple headers in the list, all of them are tested in the given order, and the first existing header in the list is used to extract the user ID (successfully or not).
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Number of events you will send on every batch reporting asynchronously to Moesif. For high throughput you will need to increase this value.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Set to true when configuring Moesif for the first time while in development, to see the activity in the logs. Set to false in production.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Sends the number of events you can hold in-memory to send them asynchronously to Moesif. If the throughput of your API generates more events than the size of the queue, the exceeding events will be discarded and not reported.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
It sets which strategy you want to use to identify the company. Identifying the company helps you efficiently govern your API. Choose the system you wish to apply (declare only one property). The claim value you access must be of type string. You can access nested structured using the dot . separator. When using dots, literals with an exact match containing the dot are checked first.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
3 nested properties
The company is identified using a header. Provide the header name.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The company is stored in a claim inside the JWT. The claim must return a string.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The company is always passed inside a query string when calling any URL. Provide the query string name.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Send the body of all endpoints and requests to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
A free-form object that allows you to push custom metadata along with events. The custom metadata appears in Moesif under a key krakend, you can use nesting if needed.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of fields in the request body that you want to mask before sending them to Moesif. You can set log_body to false to prevent any body being sent.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of request headers that you want to mask their values before sending them to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of fields in the response body that you want to mask before sending them to Moesif. You can set log_body to false to prevent any body being sent.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The list of response headers that you want to mask their values before sending them to Moesif.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Defines an expression expressed as Security Policy that avoids reporting to Moesif when the result of the evaluation is true.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
Specifies how often a background thread runs to send events to Moesif. Value in seconds.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
When using JWT tokens, it defines which claim contains the user ID. The claim value you access must be of type string. You can access nested structured using the dot . separator. When using dots, literals with an exact match containing the dot are checked first.
See: https://www.krakend.io/docs/enterprise/governance/moesif/
The New Relic integration lets you push KrakenD metrics and distributed traces to your New Relic dashboard. It uses internally the official New Relic SDK and brings its features to your APM dashboard.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
3 nested properties
The API key provided by New Relic to push data into your account.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Set to true when configuring New Relic for the first time while in development, to see the activity in the logs. Set to false in production.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Defines an explicit list of headers sent during the client request that will be reported to NewRelic, in addition to the default headers NewRelic sets. Setting the ["*"] value will send all headers sent by the client to NewRelic. Whether you declare this setting or not, you will usually receive from the NewRelic SDK the Accept, Content-Type, User-Agent, and Referer headers.
See: https://www.krakend.io/docs/enterprise/telemetry/newrelic/
Enables the extended logging capabilities.
4 nested properties
The exporter(s) you would like to enable. See each exporter configuration in its own section.
9 nested properties
Datadog is a monitoring and security platform for developers, IT operations teams and business in the cloud.
Exports data to InfluxDB: A time series database designed to handle high write and query loads.
Submit spans to a Jaeger Collector (HTTP) with endpoint or to a Jaeger Agent (UDP) with agent_endpoint.
Opencensus can export data to the system logger as another exporter. Recommended to use telemetry/logging instead.
Exporting metrics, logs, and events to the OpenCensus Agent.
Prometheus is an open-source systems monitoring and alerting toolkit.
Export metrics and traces to Google Cloud
AWS X-Ray is a service offered by Amazon that provides an end-to-end view of requests as they travel through your application, and shows a map of your application's underlying components.
Export telemetry data to a Zipkin collector
Lets you specify what data you want to export. All layers are enabled by default unless you declare this section.
3 nested properties
Reports the activity between KrakenD and your services
Reports the activity at the beginning of the proxy layer. It gives a more detailed view of the internals of the pipe between end-users and KrakenD, having into account merging of different backends.
Reports the activity between end-users and KrakenD
The number of seconds passing between reports. If duration is less than or equal to zero, it enables the default behavior of each exporter.
A number between 0 (no requests at all) and 100 (all requests) representing the percentage of sampled requests you want to send to the exporter. Sampling the 100% of the requests is generally discouraged when the relationship between traffic and dedicated resources is sparse.
Enables metrics and traces using OpenTelemetry.
9 nested properties
The places where you will send telemetry data. You can declare multiple exporters even when they are of the same type. For instance, when you have a self-hosted Grafana and would like to migrate to its cloud version and check the double reporting during the transition. There are two families of exporters: otlp or prometheus.
2 nested properties
The list of OTLP exporters you want to use. Set at least one object to push metrics and traces to an external collector using OTLP.
Set here at least the settings for one Prometheus exporter. Each exporter will start a local port that offers metrics to be pulled from KrakenD.
The environment you are deploying, this can be useful for deployment tracking. The string can have any value that makes sense to you to identify the running environment.
Use an histogram bucket configuration different from the defaults to define the detail of histogram metrics (decrease or increase their size). You don't need to set this attribute unless you want full control of the histogram definition.
2 nested properties
The size of the buckets in bytes you want to use for the histograms.
[
128,
256,
512,
1024,
4096,
8192,
16384,
32768,
65536,
262144,
524288,
1048576,
4194304,
16777216,
67108864
]The duration of buckets in seconds you want to use for the histograms.
[
0.01,
0.02,
0.05,
0.075,
0.1,
0.125,
0.15,
0.175,
0.2,
0.25,
0.3,
0.35,
0.5,
0.75,
1.0,
1.5,
2.0,
3.5,
5.0,
10.0
]A request and response flow passes through three different layers. This attribute lets you specify what data you want to export in each layer. All layers are enabled by default unless you declare this section.
3 nested properties
Reports the activity between KrakenD and each of your backend services. This is the more granular layer.
Reports the activity between end-users and KrakenD
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
How often you want to report and flush the metrics in seconds. This setting is only used by otlp exporters.
A friendly name identifying metrics reported by this installation. When unset, it uses the name attribute in the root level of the configuration.
The version you are deploying, this can be useful for deployment tracking.
The paths you don't want to report. Use the literal value used in the endpoint definition, including any {placeholders}. In the global layer, this attribute works only on metrics, because traces are initiated before there is an endpoint to match against. If you do not want any path skipped, just add an array with an empty string [""].
[
"/__health",
"/__debug/",
"/__echo/",
"/__stats/"
]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.
Enables the security layer needed to use OpenTelemetry through the Internet, like pushing data to a SaaS provider.
See: https://www.krakend.io/docs/telemetry/opentelemetry-security/
1 nested properties
The list of OTLP exporters that require authentication. Set at least one object to push metrics and traces to an external collector using OTLP.
See: https://www.krakend.io/docs/telemetry/opentelemetry-security/
Enabling TLS for HTTPS and HTTP/2.
An array with all the CA certificates you would like to load to KrakenD when using mTLS, in addition to the certificates present in the system's CA. Each certificate in the list is a relative or absolute path to the PEM file. If you have a format other than PEM, you must convert the certificate to PEM using a conversion tool. See also disable_system_ca_pool to avoid system's CA.
See: https://www.krakend.io/docs/authorization/mutual-authentication/
[]The list of cipher suites as defined in the documentation.
[
4865,
4866,
4867
]The list of all the identifiers for the curve preferences. Use 23 for CurveP256, 24 for CurveP384 or 25 for CurveP521.
[
23,
24,
25
]Ignore any certificate in the system's CA. The only certificates loaded will be the ones in the ca_certs list when true.
See: https://www.krakend.io/docs/service-settings/http-server-settings/
A flag to disable TLS (useful while in development).
Whether to enable or not Mutual Authentication. When mTLS is enabled, all KrakenD endpoints require clients to provide a known client-side X.509 authentication certificate. KrakenD relies on the system’s CA to validate certificates.
See: https://www.krakend.io/docs/authorization/mutual-authentication/
An array with all the key pairs you want the TLS to work with. You can support multiple and unrelated domains in a single process.
Maximum TLS version supported.
Minimum TLS version supported. When specifiying very old and insecure versions under TLS12 you must provide the ciphers_list.