Other Root Objects
id: This is only used in the MongoDB context and bears no actual relation to the identity of the API.
name: Human readable name of the API. It is used for identification purposes but does not act as an index.
slug: The URL segment that will map to this API, e.g. if set to widgets then the full API URL will be
api_id: The identifier for the API This should be unique, but can actually be any kind of string. For single-instance setups this can probably be set to
1. It is recommended to make this a UUID. The
api_idis used when querying the Tyk REST API for configuration details.
org_id: This is an identifier that can be set to indicate ownership of an API key or of an individual API. If the the Org ID is set (recommended), it is prepended to any keys generated by Tyk - this enables lookups by prefixes from Redis of keys that are in the system.
active: If set to
falsemeans that on start, restart or reload, the API will be ignored and all paths and routes for that API will cease to be proxied. Any keys assigned to it will still exist, though they will not be let through for that particular API.
session_lifetime: The session lifetime will override the expiry date if it has been set on a key (in seconds). for example, if a key has been created that never expires, then it will remain in the session cache forever unless manually deleted. If a re-auth needs to be forced or a default expiry needs to be applied to all keys, then use this feature to set the session expiry for an entire API.
domain: The domain to bind this API to. Domains can have multiple listen paths, so multiple APIs can be spanned across a domain using different
listen_paths, must be a valid domain name, without the protocol section (e.g. http or https). This field can support multiple domains though regular expressions (regexps). The regexp format should be defined without capturing groups -
(pattern), but non-capturing groups are allowed
(?:pattern). As an Example:
do_not_track: Set this value to true to have traffic for this API completely ignored.
enable_context_vars: Context variables are extracted from the request at the start of the middleware chain, and must be explicitly enabled in order for them to be made available to your transforms. These values can be very useful for later transformation of request data, for example, in converting a Form-based POST into a JSON-based PUT or to capture an IP address as a header. See Context Variables for more details.
config_data: You can use the config_data field in your API definition to pass custom attributes to middleware via a virtual endpoint. See Virtual Endpoints for more details.
tag_headers: This specifies a string array of HTTP headers which can be extracted and turned to tags. For example if you include X-Request-ID header to tag_headers, for each incoming request it will include a x-request-id-
tag to request an analytic record. This functionality can be useful if you need to pass additional information from the request to the analytics, without enabling detailed logging, which records the full request and response objects.