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 https://your-organisation.cloud.tyk.io/widgets.

• 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_id is 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: When used in conjunction with the dashboard, if set to false means 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. Multiple APIs can share the same domain, so long as their listen paths are unique. This domain will affect your API only. To set up the portal domain for your organisation, please register it in the main Tyk Dashboard settings file. Your Tyk Gateway can listen on multiple domains/subdomains through the use of regular expressions, more precisely the RE2 Syntax. They are defined using the format {name} or {name:pattern}.

  • www.example.com Matches only if domain is www.example.com
  • {subdomain:[a-z]+}.example.com Matches dynamic subdomain
  • {subdomain:foo|bar}.example.com will listen on foo.example.com and bar.example.com"

• 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-<header_value> 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.

• ignore_endpoint_case: New for v2.9.4. If set to true the case of a call to endpoints for this API will be ignored. So for an endpoint called getuser all the following calls will be allowed:

  • getuser
  • getUser
  • GetUser

If set to true, this will override ignoring the case for a particular endpoint with the Ignore, Blacklist and Whitelist plugins. This setting can be overriden at a “global” Tyk level by setting ignore_endpoint_case to true in your tyk.conf file. See ignore_endpoint_case for details.