Tyk Gateway API

All keys that are used to access services via Tyk correspond to a session object that informs Tyk about the context of this particular token, like access rules and rate/quota allowance.

A Tyk security policy incorporates several security options that can be applied to an API key. It acts as a template that can override individual sections of an API key (or identity) in Tyk.

Manage OAuth clients, and manage their tokens

Sometimes a cache might contain stale data, or it may just need to be cleared because of an invalid configuration. This call will purge all keys associated with a cache on an API-by-API basis.

Force restart of the Gateway or whole cluster

Check health status of the Gateway and loaded APIs

It is possible to force API quota and rate limit across all keys that belong to a specific organisation ID. Rate limiting at an organisation level is useful for creating tiered access levels and trial accounts. The Organisation rate limiting middleware works with both Quotas and Rate Limiters. In order to manage this functionality, a simple API has been put in place to manage these sessions. Although the Organisation session-limiter uses the same session object, all other security keys are optional as they are not used.

Managing active status

Tyk supports batch requests, so a client makes a single request to the API but gets a compound response object back.

This is especially handy if clients have complex requests that have multiple synchronous dependencies and do not wish to have the entire request / response cycle running for each event.

To enable batch request support, set the enable_batch_request_support value to true

This is especially handy if clients have complex requests that have multiple synchronous dependencies and do not wish to have the entire request / response cycle running for each event.

Batch requests that come into Tyk are run through the whole Tyk machinery and use a relative path to prevent spamming. This means that a batch request to Tyk for three resources with the same API key will have three requests applied to their session quota and request limiting could become active if they are being throttled.

Tyk reconstructs the API request based on the data in the batch request. This is to ensure that Tyk is not being used to proxy requests to other hosts outside of the upstream API being accessed.

Batch requests are created by POSTing to the /{listen_path}/tyk/batch/ endpoint. These requests do not require a valid key, but their request list does.

Sample Request

{
  "requests": [
    {
      "method": "GET",
      "headers": {
        "x-tyk-test": "1",
        "x-tyk-version": "1.2",
        "authorization": "1dbc83b9c431649d7698faa9797e2900f"
      },
      "body": "",
      "relative_url": "get"
  },
  {
    "method": "GET",
    "headers": {
      "x-tyk-test": "2",
      "x-tyk-version": "1.2",
      "authorization": "1dbc83b9c431649d7698faa9797e2900f"
    },
    "body": "",
    "relative_url": "get"
    }
  ],
  "suppress_parallel_execution": false
}

The response will will be a structured reply that encapsulates the responses for each of the outbound requests. If suppress_parallel_execution is set to true, requests will be made synchronously. If set to false then they will run in parallel and the response order is not guaranteed.

Sample Response

[
  {
    "relative_url": "get",
    "code": 200,
    "headers": {
      "Access-Control-Allow-Credentials": [
        "true"
      ],
      "Access-Control-Allow-Origin": [
        "*"
      ],
      "Content-Length": [
        "497"
      ],
      "Content-Type": [
        "application/json"
      ],
      "Date": [
        "Wed, 12 Nov 2014 15:32:43 GMT"
      ],
      "Server": [
        "gunicorn/18.0"
      ],
      "Via": [
        "1.1 vegur"
      ]
    },
    "body": "{
  "args": {},
  "headers": {
    "Accept-Encoding": "gzip",
    "Authorization": "1dbc83b9c431649d7698faa9797e2900f",
    "Connect-Time": "2",
    "Connection": "close",
    "Host": "httpbin.org",
    "Total-Route-Time": "0",
    "User-Agent": "Go 1.1 package http",
    "Via": "1.1 vegur",
    "X-Request-Id": "6a22499a-2776-4aa1-80c0-686581a8be4d",
    "X-Tyk-Test": "2",
    "X-Tyk-Version": "1.2"
  },
  "origin": "127.0.0.1, 62.232.114.250",
  "url": "http://httpbin.org/get"
}"
    },
    {
      "relative_url": "get",
      "code": 200,
      "headers": {
        "Access-Control-Allow-Credentials": [
          "true"
        ],
        "Access-Control-Allow-Origin": [
          "*"
        ],
        "Content-Length": [
          "497"
        ],
        "Content-Type": [
          "application/json"
        ],
        "Date": [
          "Wed, 12 Nov 2014 15:32:43 GMT"
        ],
        "Server": [
          "gunicorn/18.0"
        ],
        "Via": [
          "1.1 vegur"
        ]
      },
      "body": "{
  "args": {},
  "headers": {
    "Accept-Encoding": "gzip",
    "Authorization": "1dbc83b9c431649d7698faa9797e2900f",
    "Connect-Time": "7",
    "Connection": "close",
    "Host": "httpbin.org",
    "Total-Route-Time": "0",
    "User-Agent": "Go 1.1 package http",
    "Via": "1.1 vegur",
    "X-Request-Id": "1ab61f50-51ff-4828-a7e2-17240385a6d2",
    "X-Tyk-Test": "1",
    "X-Tyk-Version": "1.2"
  },
  "origin": "127.0.0.1, 62.232.114.250",
  "url": "http://httpbin.org/get"
}"
    }
]

With the body for each request string encoded in the body field.

• expire_analytics_after: If you are running a busy API, you may want to ensure that your MongoDB database does not overflow with old data. Set the expire_analytics_after value to the number of seconds you would like the data to last for. Setting this flag to anything above 0 will set an expireAt field for each record that is written to the database.

Important: Tyk will not create the expiry index for you. In order to implement data expiry for your analytics data, ensure that the index is created This is easily achieved using the MongoDB command line interface.

• dont_set_quota_on_create: This setting defaults to false, but if set to true, when the API is used to edit, create or add keys, the quota cache in Redis will not be re-set. By default, all updates or creates to Keys that have Quotas set will re-set the quota (This has been the default behaviour since 1.0).

  This behaviour can be bypassed on a case-by-case basis by using the suppress_reset parameter when making a REST API request. This is the advised mode of operation as it allows for manual, granular control over key quotas and reset timings.

• cache_options: This section enables you to configure the caching behaviour of Tyk and to enable or disable the caching middleware for your API.

• cache_options.enable_cache: Set this value to true if the cache should be enabled for this endpoint, setting it to false will stop all caching behaviour.

• cache_options.cache_timeout: The amount of time, in seconds, to keep cached objects, defaults to 60 seconds.

• cache_options.cache_all_safe_requests: Set this to true if you want all safe requests (GET, HEAD, OPTIONS) to be cached. This is a blanket setting for APIs where caching is required but you don't want to set individual paths up in the definition.

• cache_options.enable_upstream_cache_control: Set this to true if you want your application to control the cache options for Tyk (TTL and whether to cache or not). See Caching for more details.

• response_processors: Response processors need to be specifically defined so they are loaded on API creation, otherwise the middleware will not fire. In order to have the two main response middleware components fire, the following configuration object should be supplied.

"response_processors": [
  {
      "name": "header_injector",
      "options": {
          "add_headers": {"name": "value"},
          "remove_headers": ["name"]
      }
  },
  {
    "name": "response_body_transform",
    "options": {}
  }
]

The options for the header_injector are global, and will apply to all outbound requests.

Note: Applies only to Tyk Gateway Community Edition

API Management is very simple using the Tyk REST API: each update only affects the underlying file, and this endpoint will only work with disk based installations, not Database-backed ones.

APIs that are added this way are flushed to to disk into the app_path folder using the format: {api-id}.json. Updating existing APIs that use a different naming convention will cause those APIs to be added, which could subsequently lead to a loading error and crash if they use the same listen_path.

These methods only work on a single API node. If updating a cluster, it is important to ensure that all nodes are updated before initiating a reload.