Archived Releases

Last updated: Dec 13, 2024 38 minutes read.

2.9.0 Release Notes

TCP Proxying

Tyk now can be used as a reverse proxy for your TCP services. It means that you can put Tyk not only on top of your APIs, but on top of any network application, like databases, services using custom protocols and etc.

The main benefit of using Tyk as your TCP proxy is that functionality you used to managed your APIs now can be used for your TCP services as well. Features like load balancing, service discovery, Mutual TLS (both authorization and communication with upstream), certificate pinning: all work exactly the same way as for your HTTP APIs.

See our TCP Proxy Docs for more details.

APIs as Products

With this release we have removed all the barriers on how you can mix and match policies together, providing you with ultimate flexibility for configuring your access rules.

Now a key can have multiple policies, each containing rules for different APIs. In this case each distinct policy will have its own rate limit and quota counters. For example if the first policy gives access to API1 and second policy to API2 and API3, if you create a key with both policies, your user will have access to all three APIs, where API1 will have quotas and rate limits defined inside the first policy, and API2, API3 will have shared quotas and rate limits defined inside the second policy.

Additionally you can now mix policies defined for the same API but having different path and methods access rules. For example you can have one policy which allows only access to /users and a second policy giving user access to a /companies path. If you create a key with both policies, their access rules will be merged, and user will get access to both paths. See Multiple APIs for single Key Requests.

Developer Portal Updates

Developers now can have multiple API keys, and subscribe to multiple catalogs with a single key. Go to the Portal settings and set Enable subscribing to multiple APIs with single key option to enable this new flow. When enabled, developers will see the new API generation user interface, which allows users to request access to multiple Catalogs of the same type with a single key.

From an implementation point of view, Developer objects now have a Keys attribute, which is the map where the key is a key and the value is an array of policy IDs. The Subscriptions field can be considered as deprecated, with retained backwards compatibility. We have added new set of Developer APIs to manage the keys, similar to the deprecated subscriptions APIs.

Other changes:

Added two new Portal templates, which are used by a new key request flow portal/templates/request_multi_key.html, portal/templates/request_multi_key_success.html
The Portal Catalog list page has been updated to show the Catalog authentication mode
The API dashboard screen now show keys instead of subscriptions, and if subscribed to multiple policies, it will show the allowance rules for all catalogs.
The Key request API has been updated to accept an apply_policies array instead of for_plan

JWT and OpenID scope support

Now you can set granular permissions on per user basis, by injecting permissions to the “scope” claim of a JSON Web Token. To make it work you need to provide mapping between the scope and policy ID, and thanks to enchanced policy merging capabilities mentioned above, Tyk will read the scope value from the JWT and will generate dynamic access rules. Your JWT scopes can look like "users:read companies:write" or similar, it is up to your imagination. OpenID supports it as well, but at the moment only if your OIDC provider can generate ID tokens in JWT format (which is very common this days).

See our JWT Scope docs for more details.

Go plugins

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. The whole Tyk stack is written in Go language, and it is one of the reasons of behind our success.

With this release you now can write native Go plugins for Tyk. Which means extreme flexibility and the best performance without any overhead.

Your plugin can be as simple as:

package main
import (
	"net/http"
)
// AddFooBarHeader adds custom "Foo: Bar" header to the request
func AddFooBarHeader(rw http.ResponseWriter, r *http.Request) {
	r.Header.Add("Foo", "Bar")
}

See our Golang plugin documentation for more details.

Distributed tracing

We have listened to you, and tracing is recently one of your most common requests. Distributed tracing takes your monitoring and profiling experience to the next level, since you can see the whole request flow, even if it has complex route though multiple services. And inside this flow, you can go deep down into the details like individual middleware execution performance. At the moment we are offering OpenTracing support, with Zipkin and Jaeger as supported tracers.

See our Distributed Tracing documentation for more details.

HMAC request signing

Now Tyk can sign a request with HMAC, before sending to the upsteam target.

This feature is implemented using Draft 10 RFC.

(request-target) and all the headers of the request will be used for generating signature string. If the request doesn’t contain a Date header, middleware will add one as it is required according to above draft.

A new config option request_signing can be added in an API Definition to enable/disable the request signing. It has following format:

"request_signing": {
  "is_enabled": true,
  "secret": "xxxx",
  "key_id": "1",
  "algorithm": "hmac-sha256"
}

The following algorithms are supported:

hmac-sha1
hmac-sha256
hmac-sha384
hmac-sha512

Simplified Dashboard installation experience

We worked a lot with our clients to build a way nicer on-boarding experience for Tyk. Instead of using the command line, you can just run the Dashboard, and complete a form which will configure your Dashboard. However, we did not forget about our experienced users too, and now provide a CLI enchanced tool for bootstrapping Tyk via a command line.

See our updated Getting Started section and new CLI documentation.

DNS Caching

Added a global DNS cache in order to reduce the number of request to a Gateway’s local DNS server and the appropriate gateway config section. This feature is turned off by default.

"dns_cache": {
    "enabled": true, //Turned off by default
    "ttl": 60, //Time in seconds before the record will be removed from cache
    "multiple_ips_handle_strategy": "pick_first" //A strategy, which will be used when dns query will reply with more than 1 ip address per single host.
},

Python Plugin Improvements

We have completed a massive rewrite of our Python scripting engine in order to simplify the installation and usage of Python scripts. From now on, you no longer need to use a separate Tyk binary for Python plugins. Everything is now bundled to the main binary. This also means that you can combine JSVM, Python and Coprocess plugins inside the same installation. In addition you can now use any Python 3.x version. Tyk will automatically detect a supported version and will load the required libraries. If you have multiple Python versions available, you can specify the exact version using python_version.

Importing Custom Keys using the Dashboard API

Previously if you wanted migrate to Tyk and keep existing API keys, you had to use our low level Tyk Gateway API, which has lot of constraints, especially regarding complex setups with multiple organizations and data centers.

We have introduced a new Dashboard API for importing custom keys, which is as simple as POST /api/keys/{custom_key} {key-payload}. This new API ensures that Keys from multiple orgs will not intersect, and it also works for multi-data center setups, and even Tyk SaaS.

Single sign on for the Tyk SaaS

Before SSO was possible only for Tyk On-Premise, since it required access to low-level Dashboard Admin APIs. With 2.9 we have added new a new Dashboard SSO API, which you can use without having super admin access, and it works at the organization level. This means that all our Tyk SaaS users can use 3rd party IDPs to manage Dashboard users and Portal developers.

NOTE: This feature is available by request. Please contact our sales team for details.

See our Dashboard SSO documentation for more details.

Importing WSDL APIs

WSDL now is a first class citizen at Tyk. You can take your WSDL definition and simply import to the Dashboard, creating a nice boilerplate for your service. See Import APIs for more details.

Updated Versions

Tyk Gateway 2.9.0
Tyk Dashboard 1.9.0
Tyk Pump 0.8.0
Tyk MDCB 1.7.0

Upgrading From Version 2.8

Tyk On-Premises

For this release, you should upgrade your Tyk Pump first.

Tyk MDCB

For this release, you should upgrade your MDCB component first.

2.8.0 Release Notes

Debugger

You can now safely test all API changes without publishing them, and visually see the whole request flow, including which plugins are running and even their individual logs.

We have added a new Debugging tab in the API designer which provides a “Postman” like HTTP client interface to simulate queries for the current API definition being edited.

You can even debug your virtual endpoints by dynamically modifying the code, sending the request via Debugger and watching the virtual endpoint plugin logs.

See Debugging Tab for more information.

Developer portal oAuth support

The Developer portal now fully supports exposing oAuth2 APIs:

Developers can register their oAuth clients and see analytics
Administrators can see list of oAuth clients from a developer screen

Multi-organization users

NOTE: Currently only available with >2 node Dashboard license.

You can now create users with the same email address in different organizations. Users will then be able to select an organization when logging in, and can easily switch between organizations via the navigation menu. To enable set "enable_multi_org_users": true.

Developer management improvements

You can now manually create developer subscriptions from the developer screen.
We’ve added a quick way to change a subscription policy and reset a quota
All actions on the developer screen now only require developer permissions

Dashboard Audit Log improvements

There is a new section in the Tyk Dashboard config file where you can specify parameters for the audit log (containing audit records for all requests made to all endpoints under the /api route).

Detailed changelog

Added API Debugger tab to the API Designer.
Extended the Portal templating functionality.
Similar to the Gateway, you now can specify a list of acceptable TLS ciphers using the
http_server_options.cipher_suites array option.
Audit log improvements
Exposing oAuth2 APIs to developer portal
Allow for the retrieval of an API via it’s external API
Allow updating keys by hash
Added support for SMTP noauth.

2.7.0 Release Notes

Tyk Gateway v2.7.0

Performance improvements

TLDR To get benefit or performance improvements ensure that you have close_connections set to false and set max_idle_connections_per_host according to our production perfomance guide

We have thoroughly analyzed every part of our Gateway, and the results are astounding, up to 160% improvement, compared to our 2.6 release.

Such a performance boost comes from various factors, such as optimizing our default configs, better HTTP connection re-use, optimization of the analytics processing pipeline, regexp caching, doing fewer queries to the database, and numerous small changes in each of the middleware we have.

Our performance testing plan was focused on replicating our customer’s setup, and try not to optimize for “benchmarks”: so no supercomputers and no sub-millisecond inner DC latency. Instead, we were testing on average performance 2 CPU Linode machine, with 50ms latency between Tyk and upstream. For testing, we used the Tyk Gateway in Hybrid mode, with a default config, except for a single 2.7 change where max_idle_connections_per_host is set to 500, as apposed to 100 in 2.6. Test runner was using Locust framework and Boomer for load generation.

For a keyless API we were able to achieve 3.7K RPS (requests per second) for 2.7, while 2.6 showed about 2.5K RPS, which is a 47% improvement.

For protected APIs, when Tyk needs to track both rate limits and quotas, 2.7 shows around 3.1K RPS, while 2.6 shows around 1.2K RPS, which is 160% improvement!

In 2.7 we optimized the connection pool between Tyk and upstream, and previously max_idle_connections_per_host option was capped to 100. In 2.7 you can set it to any value. max_idle_connections_per_host by itself controls an amount of keep-alive connections between clients and Tyk. If you set this value too low, then Tyk will not re-use connections and will have to open a lot of new connections to your upstream. If you set this value too big, you may encounter issues with slow clients occupying your connection and you may reach OS limits. You can calculate the correct value using a straightforward formula: if latency between Tyk and Upstream is around 50ms, then a single connection can handle 1s / 50s = 20 requests. So if you plan to handle 2000 requests per second using Tyk, the size of your connection pool should be at least 2000 / 20 = 100. For example, on low-latency environments (like 5ms), a connection pool of 100 connections will be enough for 20k RPS.

To get the benefit of optimized connection pooling, ensure that close_connections is set to false, which enables keep-alive between Tyk and Upstream.

Custom key hashing algorithms

Key hashing is a security technique introduced inside Tyk a long time ago, which allows you to prevent storing your API tokens in database, and instead, only store their hashes. Only API consumers have access to their API tokens, and API owners have access to the hashes, which gives them access to usage and analytics in a secure manner. Time goes on, algorithms age, and to keep up with the latest security trends, we introduce a way to change algorithms used for key hashing.

This new feature is in public beta, and turned off by default, keeping old behavior when Tyk uses murmur32 algorithm. To set the custom algorithm, you need to set hash_key_function to one of the following options:

murmur32
murmur64
murmur128
sha256

MurMur non-cryptographic hash functions is considered as industry fastest and conflict-prone algorithms up to date, which gives a nice balance between security and performance. With this change you now you may choose the different hash length, depending on your organization security policies. As well, we have introduced a new sha256 cryptographic key hashing algorithm, for cases when you are willing to sacrifice performance with additional security.

Performance wise, setting new key hashing algorithms can increase key hash length, as well as key length itself, so expect that your analytics data size to grow (but not that much, up to 10%). Additionally, if you set the sha256 algorithm, it will significantly slowdown Tyk, because cryptographic functions are slow by design but very secure.

Technically wise, it is implemented by new key generation algorithms, which now embed additional metadata to the key itself, and if you are curious about the actual implementation details, feel free to check the following pull request.

Changing hashing algorithm is entirely backward compatible. All your existing keys will continue working with the old murmur32 hashing algorithm, and your new keys will use algorithm specified in Tyk config. Moreover, changing algorithms is also backward compatible, and Tyk will maintain keys multiple hashing algorithms without any issues.

Tyk Dashboard v1.7.0

User Groups

Instead of setting permissions per user, you can now create a user group, and assign it to multiple users. It works for Single Sign-On too, just specify group ID during SSO API flow.

This feature is available to all our Cloud and Hybrid users. For Self-Managed installations, this feature is available for customers with an “Unlimited” license.

To manage user groups, ensure that you have either admin or “user groups” permission for your user, which can be enabled by your admin.

From an API standpoint, user groups can be managed by new Dashboard API. The User object now has a new group_id field, and if it is specified, all permissions will be inherited from the specified group. SSO API has been updated to include group_id field as well.

Added SMTP support

Now you can configure the Dashboard to send transactional emails using your SMTP provider. See Outbound Email Configuration for details.

Upgrading all new Components

For details on upgrading all Tyk versions, see Upgrading Tyk.

Don’t Have Tyk Yet?

Get started now, for free, or contact us with any questions.

2.6.0 Release Notes

Tyk Gateway v2.6.0

Organization Level Rate Limiting

Endpoints Create organization keys and Add/update organization keys now allow you to set rate limits at an organization level. You will need to add the following fields in your create/add/update key request:

"allowance"
"rate"

These are the number of allowed requests for the specified per value, and need to be set to the same value.

"per" is the time period, in seconds.

So, if you want to restrict an organization rate limit to 100 requests per second you will need to add the following to your request:

  "allowance": 100,
  "rate": 100,
  "per": 5

NOTE: if you don’t want to have organization level rate limiting, set "rate" or "per" to zero, or don’t add them to your request.

See the Keys section of the Tyk Gateway REST API Swagger doc for more details.

Keys hashing improvements

Now it is possible to do more operations with key by hash (when we set "hash_keys": to true in tyk.conf):

endpoints POST /keys/create, POST /keys and POST /keys/{keyName} also return field "key_hash" for future use
endpoint GET /keys get all (or per API) key hashes. You can disable this endpoint by using the new tyk.conf setting enable_hashed_keys_listing (set to false by default)
endpoint GET /keys/{keyName} was modified to be able to get a key by hash. You just need provide the key hash as a keyName and call it with the new optional query parameter hashed=true. So the new format is GET /keys/{keyName}?hashed=true"
also, we already have the same optional parameter for endpoint DELETE /keys/{keyName}?hashed=true

JSON schema validation

You can now use Tyk to verify user requests against a specified JSON schema and check that the data sent to your API by a consumer is in the right format. This means you can offload data validation from your application to us.

If it’s not in the right format, then the request will be rejected. And even better, the response will be a meaningful error rather than just a ‘computer says no’.

Schema validation is implemented as for the rest of our plugins, and its configuration should be added to extended_paths in the following format:

"validate_json": [{
  "method": "POST",
  "path": "me",
  "schema": {..schema..}, // JSON object
  "error_response_code": 422 // 422 default however can override.
}]

The schema must be a draft v4 JSON Schema spec, see http://json-schema.org/specification-links.html#draft-4 for details. An example schema can look like this:

{
  "title": "Person",
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string"
    },
    "lastName": {
      "type": "string"
    },
    "age": {
      "description": "Age in years",
      "type": "integer",
      "minimum": 0
    }
  },
  "required": ["firstName", "lastName"]
}

New endpoint to get list of tokens generated for provided OAuth-client

GET /oauth/clients/{apiID}/{oauthClientId}/tokens

This endpoint allows you to retrieve a list of all current tokens and their expiry date issued for a provided API ID and OAuth-client ID in the following format. New endpoint will work only for newly created tokens:

[
  {
    "code": "5a7d110be6355b0c071cc339327563cb45174ae387f52f87a80d2496",
    "expires": 1518158407
  },
  {
    "code": "5a7d110be6355b0c071cc33988884222b0cf436eba7979c6c51d6dbd",
    "expires": 1518158594
  },
  {
    "code": "5a7d110be6355b0c071cc33990bac8b5261041c5a7d585bff291fec4",
    "expires": 1518158638
  },
  {
    "code": "5a7d110be6355b0c071cc339a66afe75521f49388065a106ef45af54",
    "expires": 1518159792
  }
]

You can control how long you want to store expired tokens in this list using oauth_token_expired_retain_period which specifies the retain period for expired tokens stored in Redis. The value is in seconds, and the default value is 0. Using the default value means expired tokens are never removed from Redis.

Creating OAuth clients with access to multiple APIs

When creating a client using POST /oauth/clients/create, the api_id is now optional - these changes make the endpoint more generic. If you provide the api_id it works the same as in previous releases. If you don’t provide the api_id the request uses policy access rights and enumerates APIs from their setting in the newly created OAuth-client.

At the moment this changes not reflected on Dashboard UI yet, as we going to do major OAuth improvements in 2.7

Certificate public key pinning

Certificate pinning is a feature which allows you to allow public keys used to generate certificates, so you will be protected in case an upstream certificate is compromised.

Using Tyk you can allow one or multiple public keys per domain. Wildcard domains are also supported.

Public keys are stored inside the Tyk certificate storage, so you can use Certificate API to manage them.

You can define them globally, from the Tyk Gateway configuration file using the security.pinned_public_keys option, or via an API definition pinned_public_keys field, using the following format:

{
  "example.com": "<key-id>",
  "foo.com": "/path/to/pub.pem",
  "*.wild.com": "<key-id>,<key-id-2>"
}

For key-id you should set the ID returned after you upload the public key using the Certificate API. Additionally, you can just set path to public key, located on your server. You can specify multiple public keys by separating their IDs by a comma.

Note that only public keys in PEM format are supported.

If public keys are not provided by your upstream, you can extract them by yourself using the following command:

openssl s_client -connect the.host.name:443 | openssl x509 -pubkey -noout

If you already have a certificate, and just need to get its public key, you can do it using the following command:

openssl x509 -pubkey -noout -in cert.pem

Note: Upstream certificates now also have wildcard domain support

JQ transformations (experimental support)

This feature is experimental and can be used only if you compile Tyk yourself own using jq tag: go build --tags 'jq'

If you work with JSON you are probably aware of the popular jq command line JSON processor. For more details, see here https://stedolan.github.io/jq/

Now you can use the full power of its queries and transformations to transform requests, responses, headers and even context variables.

We have added two new plugins:

transform_jq - for request transforms.
transform_jq_response - for response transforms

Both have the same structure, similar to the rest of our plugins: { "path": "<path>", "method": "<method>", "filter": "<content>" }

Request Transforms

Inside a request transform you can use following variables:

.body - your current request body
._tyk_context - Tyk context variables. You can use it to access request headers as well.

Your JQ request transform should return an object in the following format: { "body": <transformed-body>, "rewrite_headers": <set-or-add-headers>, "tyk_context": <set-or-add-context-vars> }.

body is required, while rewrite_headers and tyk_context are optional.

Response Transforms

Inside a response transform you can use following variables:

.body - your current response body
._tyk_context - Tyk context variables. You can use it to access request headers as well.
._tyk_response_headers - Access to response headers

Your JQ response transform should return an object in the following format: { "body": <transformed-body>, "rewrite_headers": <set-or-add-headers>}.

body is required, while rewrite_headers is optional.

Example

"extended_paths": {
  "transform_jq": [{
    "path": "/post",
    "method": "POST",
    "filter": "{\"body\": (.body + {\"TRANSFORMED-REQUEST-BY-JQ\": true, path: ._tyk_context.path, user_agent: ._tyk_context.headers_User_Agent}), \"rewrite_headers\": {\"X-added-rewrite-headers\": \"test\"}, \"tyk_context\": {\"m2m_origin\": \"CSE3219/C9886\", \"deviceid\": .body.DEVICEID}}"
   }],
  "transform_jq_response": [{
    "path": "/post",
    "method": "POST",
    "filter": "{\"body\": (.body + {\"TRANSFORMED-RESPONSE-BY-JQ\": true, \"HEADERS-OF-RESPONSE\": ._tyk_response_headers}), \"rewrite_headers\": {\"JQ-Response-header\": .body.origin}}"
  }]
}

Tyk Dashboard v1.6.0

API categories

You can apply multiple categories to an API definition, and then filter by these categories on the API list page.

They might refer to the APIs general focus: ‘weather’, ‘share prices’; geographic location ‘APAC’, ‘EMEA’; or technical markers ‘Dev’, ‘Test’. It’s completely up to you.

From an API perspective, categories are stored inside API definition name field like this: “Api name #category1 #category2”, e.g. categories just appended to the end of the name.

Added new API /api/apis/categories to return list of all categories and belonging APIs.

Raw API Definition mode

Now you can directly edit a raw API definition JSON object directly from the API Designer, by selecting either the Raw API Definition or the API Designer at the top of the API Designer screen.

Raw or Designer

This feature comes especially handy if you need copy paste parts of one API to another, or if you need to access fields not yet exposed to the Dashboard UI.

Certificate public key pinning

You can configure certificate pinning on the Advanced tab of the API Designer, using a similar method to how you specify upstream client certificates.

Certificate Pinning

JSON schema validation

Reflecting the Tyk Gateway changes, on the Dashboard we have added a new Validate JSON plugin, which you can specify per URL, and can set both a schema, and custom error code, if needed.

Improved key hashing support

The Tyk Dashboard API reflects changes made in the v2.6.0 Gateway API, and now supports more operations with key by hash (when we have set "hash_keys": to true in tyk_analytics.conf):

endpoint POST /keys/ also returns a new field key_hash per each key in the list
endpoint GET /apis/{apiId}/keys/{keyId} supports query string parameter hashed=true to get the key info via hash
endpoint GET /apis/{apiId}/keys returns keys hashes
endpoint DELETE /apis/{apiId}/keys?hashed=true can delete a key by its hash, but its functionality is disabled by default, unless you set enable_delete_key_by_hash boolean option inside the Dashboard configuration file.

Key requests management API now supports OAuth

For this release we’ve improved our developer portal APIs to fully support an OAuth2.0 based workflow. Developers using your API will now be able to register OAuth clients and manage them.

This change is not yet supported by our built-in portal, but if you are using custom developer portals, you can start using this new functionality right away. Full UI support for built-in portal will be shipped with our next 2.7 release.

Developers can request access to an API protected with OAuth and get OAuth client credentials.

The endpoint POST /api/portal/requests now has an optional "oauth_info" field which identifies the OAuth key request.

Example of the OAuth key request:

{
  "by_user": "5a3b2e7798b28f03a4b7b3f0",
  "date_created": "2018-01-15T04:49:20.992-04:00",
  "for_plan": "5a52dfce1c3b4802c10053c8",
  "version": "v2",
  "oauth_info": {
    "redirect_uri": "http://new1.com,http://new2.com"
  }
}

Where:

"by_user" - contains the ID of portal developer who is requesting OAuth access
"for_plan" - subscription ID
"version" - is expected to have the value "v2"
"oauth_info" - simple structure which contains a field with comma-separated list of redirect URI for OAuth flow

A new field "oauth_info" will be present in replies for endpoints GET /api/portal/requests/{id} and GET /api/portal/requests

When this kind of OAuth key request gets approved when using endpoint PUT /api/portal/requests/approve/{id} a new OAuth-client is generated for a developer specified in the specified "by_user" field.

Example of OAuth key request approval reply:

{
    "client_id": "203defa5162b42708c6bcafcfa28c9fb",
    "secret": "YjUxZDJjNmYtMzgwMy00YzllLWI2YzctYTUxODQ4ODYwNWQw",
    "policy_id": "5a52dfce1c3b4802c10053c8",
    "redirect_uri": "http://new1.com,http://new2.com"
}

Where:

"client_id" and "secret" are OAuth-client credentials used to request the get token (they are to be kept in secret)
"policy_id" - the subscription this OAuth-client provides access to
"redirect_uri" - with comma-separated list of redirect URI for OAuth flow

Also, if you set email notifications in your portal, an email with the OAuth-client credentials will be sent to the developer who made that OAuth key request.

There is also a change in the reply from the GET /api/portal/developers endpoint.The developer object will have new field - "oauth_clients" which will contain a mapping of subscription IDs to the list of OAuth clients that the developer requested and was approved, i.e.:

"oauth_clients": {
  "5a52dfce1c3b4802c10053c8": [
    {
      "client_id": "203defa5162b42708c6bcafcfa28c9fb",
      "redirect_uri": "http://new1.com,http://new2.com",
      "secret": "YjUxZDJjNmYtMzgwMy00YzllLWI2YzctYTUxODQ4ODYwNWQw"
    }
  ]
},

New endpoints to get tokens per OAuth client

These endpoints allow you to get a list of all current tokens issued for provided OAuth client ID:

GET /apis/oauth/{apiId}/{oauthClientId}/tokens
GET /apis/oauth/{oauthClientId}/tokens when the API ID is unknown or OAuth-client provides access to several APIs

Renamed the response `_id` field to `id` in List Key Requests

We have renamed the response _id field when retrieving a list of key requests to id.

See List Key Requests for more details.

Developers can request a password reset email

If a developer forgets their password, they can now request a password reset email from the Developer Portal Login screen.

Request email reset

See Developer Profiles for more details.

SSO API custom email support

Now you can set email address for users logging though the Dashboard SSO API, by adding an “Email” field to the JSON payload which you sent to /admin/sso endpoint. For example:

POST /admin/sso HTTP/1.1
Host: localhost:3000
admin-auth: 12345
    
{
  "ForSection": "dashboard",
  "Email": "[email protected]",
  "OrgID": "588b4f0bb275ff0001cc7471"
}

Set Catalog settings for each individual API

Now you can override the global catalog settings and specify settings per catalog. The Catalog object now has config field, with exactly same structure as Portal Config, except new override boolean field. If set, Catalog settings will override global ones.

At the moment the following options can be overriden: Key request fields, Require key approval and Redirect on key request (with Redirect to option as well).

Blocklist¹ IP Support

Tyk allows you to block IP Addresses, which is located in the Advanced Options tab in the Endpoint Designer.

Blocklist Support

Tyk Identity Broker v0.4.0

With this release TIB joins the Tyk product line as a first class citizen and is now distributed via packages and Docker image.

Support for SSO API email field

If IDP provides a user email, it should be passed to the Dashboard SSO API, and you should see it in the Dashboard UI.

Improved support for local IDPs

If you run a local IDP, like Ping, with an untrusted SSL certificate, you can now turn off SSL verification by setting SSLInsecureSkipVerify to true in the TIB configuration file.

Added Redis TLS support

To enable set BackEnd.UseSSL and, optionally, BackEnd.SSLInsecureSkipVerify.

Tyk Pump v0.5.2

Redis TLS support

Added new redis_use_ssl and redis_ssl_insecure_skip_verify options.

Redis TLS support

Many Redis hosting providers now support TLS and we’re pleased to confirm that we do too.

Whether it’s the open source API Gateway, or Dashboard, Pump, Sink and Tyk Identity Broker (TIB): you can now make secure connections to Redis from all Tyk products, as long as your provider allows it.

MDCB v1.5.3

Redis TLS support

Added new redis_use_ssl and redis_ssl_insecure_skip_verify options.

Upgrading all new Components

For details on upgrading all Tyk versions, see Upgrading Tyk.

Don’t Have Tyk Yet?

Get started now, for free, or contact us with any questions.

2.5.0 Release Notes

This release touches all our products and brings you numerous features and fixes. Here are the packages and their versions we are releasing today: Tyk Gateway v2.5.0, Tyk Dashboard v1.5.0, Tyk Pump v0.6.0, MDCB v1.5.0, TIB v0.3.

Major Highlights

New Dashboard Look and Feel

Our Dashboard has had a UI overhaul, with the following improvements:

A more modern, fun look and feel
Consistent layouts and action buttons across each section
Better feedback on errors and updates
Various UX improvements

SSO with OpenId Identity Providers

With TIB v0.3 we have made it possible to integrate any OpenID supported Identity provider with Tyk so you can configure Single Sign On (SSO), if the provider supports those.

Searching API and Policies List

This long awaited feature has been added on the Dashboard UI.

Default API Versioning

You can now specify a default API version when using a versioning strategy.

Tyk Pump with MDCB

We’ve added MDCB support in this release of Tyk Pump

Tyk Gateway v2.5.0

New Relic Instrumentation Support

We have added support for New Relic Instrumentation using:

"newrelic": {"app_name": "<app-id>", "license_key": "<key>"}

Archived Releases

2.9.0 Release Notes

TCP Proxying

APIs as Products

Developer Portal Updates

JWT and OpenID scope support

Go plugins

Distributed tracing

HMAC request signing

Simplified Dashboard installation experience

DNS Caching

Python Plugin Improvements

Importing Custom Keys using the Dashboard API

Single sign on for the Tyk SaaS

Importing WSDL APIs

Updated Versions

Upgrading From Version 2.8

Tyk On-Premises

Tyk MDCB

2.8.0 Release Notes

Debugger

Developer portal oAuth support

Multi-organization users

Developer management improvements

Dashboard Audit Log improvements

Detailed changelog

2.7.0 Release Notes

Tyk Gateway v2.7.0

Performance improvements

Custom key hashing algorithms

Tyk Dashboard v1.7.0

User Groups

Added SMTP support

Upgrading all new Components

Don’t Have Tyk Yet?

2.6.0 Release Notes

Tyk Gateway v2.6.0

Organization Level Rate Limiting

Keys hashing improvements

JSON schema validation

New endpoint to get list of tokens generated for provided OAuth-client

Creating OAuth clients with access to multiple APIs

Certificate public key pinning

JQ transformations (experimental support)

Request Transforms

Response Transforms

Example

Tyk Dashboard v1.6.0

API categories

Raw API Definition mode

Certificate public key pinning

JSON schema validation

Improved key hashing support

Key requests management API now supports OAuth

New endpoints to get tokens per OAuth client

Renamed the response _id field to id in List Key Requests

Developers can request a password reset email

SSO API custom email support

Set Catalog settings for each individual API

Blocklist1 IP Support

Tyk Identity Broker v0.4.0

Support for SSO API email field

Improved support for local IDPs

Added Redis TLS support

Tyk Pump v0.5.2

Redis TLS support

Redis TLS support

MDCB v1.5.3

Redis TLS support

Upgrading all new Components

Don’t Have Tyk Yet?

2.5.0 Release Notes

Major Highlights

New Dashboard Look and Feel

SSO with OpenId Identity Providers

Searching API and Policies List

Default API Versioning

Tyk Pump with MDCB

Tyk Gateway v2.5.0

New Relic Instrumentation Support

Renamed the response `_id` field to `id` in List Key Requests

Blocklist¹ IP Support

Include `x-tyk-api-expires` date header for versioned APIs

`tyk_js_path` file now contains only user code