Tyk News

All the latest news & updates on the Tyk API Management Platform

How APIs Are Creating the Composable Enterprise

James Higginbotham recently spoke at APIStrat 2016 in Boston, where he shared some insights into how enterprises are using APIs and microservices as part of their digital transformation processes. What does this mean for software architects in today’s enterprise? Let’s first look at the transformations underway toward a composable, modular enterprise. Then we will consider some of the impacts it will have on our day-to-day efforts as software architects.

What is the Composable Enterprise?

The composable enterprise is one that strives to capture business and technical capabilities as APIs, seen as modular components across lines of business. Apps and integrations are built upon these APIs by the enterprise for internal, partner, or public use. A composable enterprise combines commercial off the shelf (COTS) packages, SaaS platforms, and custom development to address market needs quickly.

Coming from a software background, I tend to think of it more like a modular enterprise with APIs that can be combined to create new and interesting solutions:

Capital One is one enterprise moving in this direction by releasing a few public productized APIs, with the rest remaining for private or partner consumption.

Moving Toward an API-Centric Architecture

Within the enterprise, APIs are traditionally viewed as bolt-on solutions. They connect internal systems together, or offer enterprise data to remote mobile or web apps. However, reuse isn’t the goal of an integration API, resulting in one-off APIs scattered across the organization. In a composable enterprise, APIs are designed first, becoming the outward-facing contract that hides all of the internal details:

Legacy systems can then be transitioned to a new architecture or replaced with a new solution over time. Whether you are wrapping a commercial product, monolithic application, or a microservice architecture – it doesn’t matter.

APIs Should Focus on Capabilities

APIs in a composable enterprise focus on delivering business and technical capabilities. This requires that we shift our thinking from databases and code to helping people achieve their goals. Users don’t care how we organize our database schema, what programming languages we use, and what the current hot server or client-side framework may be. They want to get things done and move on. As architects, we need to focus on both the business and technology – APIs are the key deliverable that is shared between them. Our API designs should focus on delivering desired outcomes, not just data.

Manage Your API as a Product

The traditional view of APIs results in APIs being treated the same as internal code, with limited access or visibility. Applying product-thinking to APIs requires a shift toward developer portals, self on-boarding of developers, and a customer-driven approach. Most importantly, architects must monitor API usage, making adjustments to the API product based on consumption patterns.

At the center of a product-driven architecture is an API gateway and management layer. The gateway routes incoming API requests to internal processes or microservices. The management layer provides security, role-based enforcement, rate limiting, and usage metrics. A variety of commercial and open source solutions exist to fill this gap. Tyk is an open source solution that offers a cloud, hybrid or on-premise option to solving this problem.

Want to Learn More About the Composable Enterprise?

You can view the slide deck from the presentation, available via Slideshare.

Tyk API Gateway v2.3 released

Sweet Shyamalamadingdong! Tyk v2.3 is out!

If API Gateways were professional wrestlers, Tyk would probably be a Luchador… she would use different stage names: Pirata Rosa, Presidente Misterioso, or La Fenix Mayor, and each persona would instill quivering anticipation with onlookers: “No! Not Pirata Rosa!” they would whisper in their lunch break, “I heard she made El Ruso Picante eat his own mask, after she kicked his ass with a rubber chicken….”

“This one time, La Fenix Mayor strolled into the ring,” they said in hushed tones, “she took one of the fans of El Coyote Magico, and then beat him to death with his own feet!”, tickets to her shows would sell in the millions, her fans would be adoring, her fame would spread across the world and she would be so renowned that the Mayor of Funkytown would need to erect a statue to her honor… Tyk the API Gateway, the Luchador-of-Luchadores, the Beater-of-things, oh it would be magical…

Ok, so maybe I’m going totally off-topic here… we’re here to talk about the newest, shiniest, most kick-ass-iest API Gateway update in the history of API Gateway updates.

So what’s new pussycat? Let. Me. Tell. You:

Performance, performance, performance, performance… wait, did I mention performance? Performance.

That’s right: Tyk v2.3 can handle more than twice the traffic that v2.2 could, on top of that, it’s more efficient in how it handles Redis, and it’s more clever in how it manages its traffic.

The latest incarnation of Tyk comes with a distributed rate limiter. This new module means that Tyk no longer needs to synchronise rate limits across a cluster via Redis, and instead does so by ongoing inter-cluster chatter and a distributed in-memory token-based limiter that is eventually consistent, instead of hard-synchronised.

The new rate limiter is also more forgiving, if you set a limit of 1 request per second, then one request per second will always get through, whereas previously the client would need to implement some kind of back-off strategy.

This also means an overall reduction in the amount of Redis traffic coming from the Gateway that ensures that the Gateways scale effectively as CPU cores increase.

And all of that culminates in a really cool, auto-scaling system that can handle a bunch of traffic, efficiently and effectively.

You want to extend Tyk? Have I got some news for you…

So if Tyk were a wrestler, then if she were to use a weapon outside of the ring (as you do), unlike most other wrestlers that are limited to using only one tool, usually a poor spectator’s chair. Tyk – or La Fenix Mayor!, to use her nom-de-souffrance – will use the spectator’s chair, the spectator’s backpack, the spectator’s handkerchief, or even the poor spectator themselves to beat her opponent to a whimpering mess.

(That’s quite a strained metaphor, I’ll admit.)

What we’re saying is that in Tyk v2.3 you can add pre-processing, post-processing, and custom authentication middleware in more than just one host language. With Tyk, you can add plugins using… clears throat, drumroll:

That’s right, if you want to add a custom authentication server to Tyk and you want it to be fast, you can use any of the above to extend how Tyk works.

The new plugins feature means that on top of all the native goodies that come with Tyk out of the box, extending it now fits the needs of your team and not what we (or anyone else) impose on you. It’s all about flexibility and performance, and here, we perform very well.


While Tyk v2.3 can easily handle 2,000 requests on commodity hardware, when you start introducing plugins and host languages you can see a bit of a performance hit, but that performance hit, in Tyk, is designed to still be plenty fast. In our benchmarking, Python 3 plugins performed at about 1,300 requests per second with sub-100ms latency, while gRPC with a local gRPC host gave us 1,400 requests per second with sub-100ms latency.

This is important, so I’m going to say it again: You can extend Tyk with almost any language you chose, and get blazing-fast performance to boot.

Pre-built plugins

Now we’re not saying “we have all this cool new stuff for you but you need to do it yourself”. Hell no! We always like to add value – just look at all the cool features that come built into Tyk natively. No, we like to go further, to go deeper. With this release, we’ve also been hard at work fashioning some initial plugins that are 1, pretty damned useful, and 2, a great starting point for setting up your own.

Some of the more awesome plugins that we’ve put together are:

  • Loggly integration
  • Datadog integration
  • Bot detection
  • Message Queue integration (AMQP amongst other message queue hand-offs)
  • Webhook sidecar
  • Correlation IDs for request logging

We’ve also generated demo’s to get you started in your favourite languages for:

And we’ll keep going…

Is this the future of Tyk?

In a word: No. Unlike other vendors, we like to pack value into our offering, and we don’t want to take the chicken-sh*t way out and force our customers to maintain their own plugins, or forks of ours in order to add functionality to Tyk. We don’t want you to increase your technical debt by having to maintain customisations to Tyk over huge swathes of time.

So our plan is to continue adding great functionality to the Tyk OSS core, and even migrating popular plugins into the core so that they are available to all “at the speed of Go”, while giving our users the flexibility and capability to make it easy to integrate Tyk with your systems.

In future, we may opt for creating plugins for Tyk in Go itself, at which point things may change, but for now: Tyk is there to make sure that you can get your sh*t done and get it done well.

Other cool stuff

So the above two features are pretty much the biggest, baddest announcements that come with Tyk wading into the ring with v2.3, but we have also been busy fixing up bugs and adding smaller, nice-to-have features to the overall system, I’ve listed a few below because they are pretty cool, and it’s nicer to read them here rather than parsing our changelog:

Environment variable configuration

This is a dull, but very useful change – you can now configure all of the Tyk Gateway, Analytics and Pump settings via environment variables – more precisely – you can override them. This is extremely useful for those of you deploying into Docker orchestration environments such as Kubernetes where files aren’t fun to deploy.

Live Gateway logs in the Dashboard

A lot of the debug information in Tyk comes from the Gateway log (stderr) output, so we’ve made it so that key log operations are also copied through to a live Dashboard view – this way you can quickly check why an API hasn’t loaded or if a system event or error has occurred without reaching for the raw logs from the Gateway hosts.

Custom error templates per response code in XML or JSON

This is a popular request, you can override all of our error templates, per-status-code, in either XML or JSON, this means you can have much more control over how your API Gateway responds to end users when errors occur.

Chained authentication methods

A popular request from the community – having the capability to have HMAC-based message signing in conjunction with a bearer token. With this mechanism, you can actually use many different authentication methods chained together in order to provide maximum security for your applications.

Hot reconfigure and reload of the Tyk Gateway process from the Dashboard

Tyk has always been able to hot-reload from the command line, but we’ve made the process smoother and more efficient, not only can you send a signal to the process to fork and start a new process without dropping any connectionss, but you can also hot reload from the Dashboard and also re-configure the Gateway in the process without having to set foot on the host.

(Naturally, this feature can be disabled!)

A new CLI tool to help you build and deploy plugins

Having so many plugin options means we needed a better way to publish your code to the Gateway layer, and to make that work, we’ve started work on a CLI tool, this tool currently can only do one thing: sign and package up your plugins so that they are cryptographically secure and guaranteed before being deployed (and verified) by the Gateway.

But this project will keep growing, and more and more functionality will be added to the CLI to make it easy to script common Gateway operations.

More logger integrations

Tyk v2.3 now has logger integrations for:

So that you can aggregate your Gateway logs into the system of your choice.

Separate Redis cache

For those using our caching mechanism, in very high availability environments you do not want to have your Redis cache be the same database that is used by Tyk for configuration information. With this update it is possible to completely separate out the cache to a different Redis database or cluster.

More portability: Import/Export API

It is now possible to backup and re-create your Organisations, Policies and APIs using a dedicated import/export API. This will allow you to completely re-generate an installation from backed up assets without worrying about mis-attributed IDs.

LetsEncrypt support

A fun, and currently experimental feature, the Tyk Gateway can now auto-provision SSL certificates for your domain-bound APIs so you do not need to configure them yourself. All certificate information is encrypted and shared across a cluster so that subsequent visits to your Gateways are fast and scaleable.

That’s all folks

Until we meet again – we’re already planning v2.4 and have some very cool stuff in the pipeline for you. As always, get in touch with us on the community forum, or directly via Twitter, to give us feedback or ask any questions.

For those of you on v2.2, we have created some upgrade notes.

Now… back to the ring.

Martin and the team at Tyk Towers in Shoreditch, London.


SDK Patterns For Accelerating API Integration

Here at Tyk we find that everyone has a different opinion when it comes to SDKs: Some think they are the best thing since sliced bread, whilst others think they suck and are a waste of time. The truth is usually somewhere in between.

James Higginbotham was at API Days last month – Let’s hear what he found out about the latest SDK trends.


I recently attended APIStrat 2016 in Boston, where there was plenty of discussion around the practices of providing and consuming APIs. One thing that was notable was the reemergence of SDKs for APIs. Rather than in previous years, the discussion wasn’t on SDK vs. no-SDK. Instead, the discussion was on the various ways we could empower API consumers to quickly integrate API providers into their solutions. Out of these discussions came 4 patterns on how API providers can offer SDKs to help their API consumers integrate quickly. Let’s revisit what an SDK is, and then examine these 4 patterns to see what may be the best fit for your API.

What is an SDK?

A Software Developer Kit, or SDK, is a packaged solution that includes code for developers that wish to interact with a web-based API. SDKs target a specific programming language or runtime platform, such as Java/the JVM, Ruby, JavaScript, PHP, Python, Perl, or Golang.

SDKs speed the integration process between a server-side or client-side/mobile application and the web API. They often include one or more of the following:

  • A client library for the specific programming language, removing the need to deal with the lower-level details of HTTP request/response
  • SDK documentation that describe how to use the client library
  • Example scripts and/or full applications that demonstrate SDK usage
  • Administration/CLI scripts for interacting with the API from the command-line to prevent the need for writing code for common administrative functions

Are SDKs the same as helper libraries?

Traditionally, SDKs include more than client libraries, as noted above. Some API providers offer helper libraries, which simply offer a language-specific distribution of a client library. All other resources often found in an SDK are hosted on their website for reference.

While there is a distinct difference between an SDK and helper library, many (like myself) tend to use the term interchangeably. The important thing is to be clear about what is provided in the distribution to set proper expectations with the developer. Providing a clear README file inside the distribution with links to additional documentation and resources is also a good practice, as it will help developers get started quickly.

SDK Patterns for API Providers

Now that we understand what SDKs are, we need to determine who will build and maintain them. There are four distinct patterns for providing SDKs:

Provider supported: Vendor supported SDKs are built and maintained by the API provider. They own them, manage them, and keep them in sync as API endpoints are added or enhanced.

Community contributed: Instead of the vendor offering the SDK, the community contributes the SDK – often through Github or similar. This may be the case for all SDKs, or just for less popular programming languages that the vendor has not offered. Vendors may choose to allow the community-contributed SDKs to thrive on their own, work with the author(s) to make them better, or eventually offer to take over maintenance of the SDKs. Be aware that community-contributed SDKs have a tendency to lose interest or available maintainers over time and may become abandoned. Communication with community supporters is critical, as many developers may assume they are vendor-backed and complain if they are no longer maintained.

Consumer-driven: With the growth of API definition formats such as Swagger, RAML, Blueprint, and others, it is becoming easier for API consumers to generate their own client library from any of these formats. This gives the consumer the most flexibility, as they may opt to create a lightweight wrapper around the HTTP layer, or perhaps generate a robust library with objects/structures that mimic API resources.

HTTP is the SDK: Those familiar with HTTP generally prefer working with it directly rather than an SDK. SDKs often hide the lower-level details of HTTP and may prevent tuning API consumption to fit the exact needs of the use case. Offering examples using cURL and in popular programming languages can help get them started, without the overhead of needing to learn a brand new SDK library.

Which Approach Is Right For Your API?

Some have made the case that SDKs create more challenges for both API providers and consumers, preferring in most cases to simply offer well-documented APIs for developers to make HTTP requests. However, there are times when it makes sense. This is especially the case in the mobile space, where developers are accustomed to installing an SDK and coding against it rather than composing raw HTTP requests and handling the responses themselves.

Understanding your API consumer audience is the best way to make a decision. When in doubt, start with great documentation and using an API definition language such as Swagger, RAML, or Blueprint. Consumer-driven SDKs enable developers to work directly with HTTP, then generate their own SDK as desired. You can then begin to offer SDKs for specific programming languages when your team is ready to fully support them.

Why Do Microservices Need an API Gateway?

Sometimes everything depends on a powerful gateway. Covering security, control and the power of transforms, James Higginbotham explores the ways microservice architectures can benefit from an API Gateway.


With the growth of API as a product, as well as API-centric IT initiatives, API gateways and management layers are becoming more common place. But, should we consider an API gateway for our microservices as well? If so, what kind of benefits do they offer?

What is an API Gateway?

An API gateway provides a single, unified API entry point across one or more internal APIs. They typically layer rate limiting and security as well. An API management layer, such as Tyk.io, adds additional capabilities such as analytics, monetisation, and lifecycle management.

A microservice-based architecture may have from 10 to 100 or more services. An API gateway can help provide a unified entry point for external consumers, independent of the number and composition of internal microservices.

The Benefits of an API Gateway For Microservices

Prevents exposing internal concerns to external clients. An API gateway separates external public APIs From internal microservice APIs, allowing for microservices to be added and boundaries changed. The result is the ability to refactor and right-size microservices over time, without negatively impacting externally-bound clients. It also hides service discovery and versioning details from the client by providing a single point of entry for all of your microservices.

Adds an additional layer of security to your microservices. API gateways help to prevent malicious attacks by providing an additional layer of protection from attack vectors such as SQL Injection, XML Parser exploits, and denial-of-service (DoS) attacks.

Enables support for mixing communication protocols. While external-facing APIs commonly offer an HTTP or REST-based API, internal microservices may benefit from using different communication protocols. Protocols may include ProtoBuf, AMQP, or perhaps system integration with SOAP, JSON-RPC, or XML-RPC. An API gateway can provide an external, unified REST-based API across these various protocols, allowing teams to choose what best fits the internal architecture.

Decreased microservice complexity. Microservices have common concerns, such as: authorization using API tokens, access control enforcement, and rate limiting. Each of these concerns can add more time to the development of microservices by requiring that each service implement them. An API gateway will remove these concerns from your code, allowing your microservices to focus on the task at hand.

Microservice Mocking and Virtualization. By separating microservice APIs from the external API, you can mock or virtualize your services to validate design requirements or assist in integration testing.

The Drawbacks of an Microservice API Gateway

While there are many benefits to using an API microservice gateway, there are some downsides:

  • Your deployment architecture will require more orchestration and management with the addition of an API gateway
  • Configuration of the routing logic must be managed during deployment, to ensure proper routing from the external API to the proper microservice
  • Unless properly architected for high availability and scale, an API gateway can become a limiting factor and even a single point of failure

Using Tyk For Your Microservice Gateway

Rather than providing an explanation of Tyk’s features as a microservice API gateway, I’ll let Dave Koston, VP Engineering at Help.com explain how they use Tyk:

“We use Tyk as a gateway in front of around 15 services (of varying sizes). We’re also using Tyk Identity Broker to proxy logins to our existing authentication service. Tyk gives us some really great features out of the box like rate limiting, sessions, token policies, and visibility into api traffic.”

In addition, Dave mentioned that Tyk helps them secure their web socket connections, in addition to their API:

“We also have web socket communication that requires authentication and it was easy to simply add some metadata to Tyk sessions and use the Tyk session store (Redis in our case) to authenticate those web socket connections with the same access token that we use for HTTP.”

To learn more about Tyk and how it can provide an API gateway for your microservices, along with API management of your public API, take a look at our product page.

7 Critical Factors For Selecting Your API Management Layer

Remember the final scene of Indiana Jones and the Last Crusade, where the old Knight says: “You must choose, but choose wisely”? Admittedly Indy wasn’t choosing an API Management Solution and certainly had other things on his plate that day. However the adage still applies and to help you choose wisely we’ve got James Higginbotham, who has put together a list of the seven critical factors to consider when choosing your API Management Layer.


I’m often asked which API management layer is the best one available today. The answer is always, “It depends”. Whether you are considering an open source or closed source API management layer, the number of vendors and options available today are astounding. Many API management solutions focus on delivering specific capabilities, while others strive to cover a breadth of features but don’t go very deep in all areas. This article will shed some light on how to approach the decision making process for managing your API, so that you can ensure the needs of your business, product, and development teams are met.

Why Do You Need API Management?

For those unfamiliar, API management layers accelerate the deployment, monitoring, security, versioning, and sharing of APIs. They are often deployed as a reverse proxy, intercepting all incoming API request traffic and applying rules to determine if requests should be routed to the API. In addition to traffic management, they commonly offer:

  • Token-based authorization support through API-key based authentication and/or OAuth 2
  • Deployment and versioning support for redirecting incoming requests to the current or newly deployed release of an API
  • Rate limiting to reduce the impact of greedy API clients and denial of service (DoS) attacks
  • Developer portals for hosted documentation and self-onboarding by developers
  • Administrative portals for viewing usage reports
  • Billing and payment support for selling subscription-based access to your API
  • On-premise, cloud, and hybrid hosting deployment options

API management layers may be offered as purely closed source, purely open source, or in a hybrid model using a combination of open source components and closed source offerings.

Factor #1: Self-hosted and SaaS deployment options

Your deployment requirements are a huge factor in API management layer selection. While most vendors offer managed cloud-based options, some choose to do so only during the early stages of your API, requiring you to move to an on-premise solution as your traffic increases. Knowing how you need to deploy your API management layer, including the resources available to monitor and maintain it, is important to the selection process. Look for a vendor that offers the kind of deployment you require: on-premise or managed cloud services. If you are unsure, select a vendor that offers a seamless transition from one to the other, such as Tyk.io.

Factor #2: Simple installation process

If your API management layer will reside within your own cloud environment or data center rather than hosted, then installation needs to be simple. Evaluate the installation process to ensure that standing up new instances and new environments (e.g. staging, UAT, integration) will be easy – and preferably automated. If you prefer containerization, consider vendors that offer a container-based distribution to reduce the effort required to support your deployment process.

Factor #3: Meets feature requirements

Part of your selection process should include an evaluation. We covered this in a previous article, but I’ll repeat it here for reference. Your evaluation should include the following considerations:

  • Authorization – can you implement your desired authorization mechanism (e.g. API tokens, keys, OAuth 2, etc) to meet your needs?
  • Performance – how much overhead does the layer require for each request? Measure the performance of your API endpoints before and after installing the API management layer. Expect some reduction in performance, but also ensure that the management layer doesn’t cause a drastic decrease in performance that may require additional server capacity
  • Security – perform some basic penetration testing to verify that the layer is catching common attack vectors. Attacks such as SQL injection, denial of service attack prevention through rate limiting, and other attacks can often be simulated with some simple scripts
  • Onboarding – how easy or hard will it be for your developers to get onboarded? Does the onboarding process support the business, product, and technical needs of your company?
  • Reporting – does the management layer provide the information you will need on a day-to-day basis to better serve your developers? Can you export data via an API or push it into an external reporting solution easily, for integration into other daily/weekly reports?

Factor #4: Customization should not be required

I was recently discussing the abundance of infrastructure tools available to development teams today. With every tool comes the burden of understanding it and getting it integrated into your environment. Some tools choose to offer a variety of options, but require considerable effort to get them running. Be sure to evaluate the effort required to start using the API management layer. Customization options are great, but if you can’t get started easily or without installing lots of plugins, you need to know this ahead of time.

Factor #5: Easy upgrades

Whatever solution you select, you will need to keep it upgraded to ensure you have the latest improvements and available features. Evaluate the upgrade process by reading past release notes to better understand the process that will likely be required. If there are no release or upgrade notes, then that should generate a concern. Just keep in mind that some commercial offerings only supply these details directly to customers or via a customer portal. If you don’t find anything, contact the vendor to ensure that they are available to paying customers.

Factor #6: Vendor viability

We all want API management vendors to experience growth and success. However, not everyone will be around in the long term. Consider the vendor’s viability by understanding their revenue model. For open source solutions, take into consideration the companies backing the solution, along with the community that is supporting it. If there isn’t much activity, then the solution may become abandoned in the future.

Factor #7: Management Automation

Finally, consider the automation options available to configure, manage, and integrate the solution into your operations processes. Vendors that offer APIs for every feature available in their configuration APIs, along with reporting APIs and webhooks for important events ensure that you can easily automate changes and integrate it into your deployment process.


As you have likely realized, it isn’t easy to select an API management layer. However, your decision will have ramifications for months or years to come. It may offer tremendous flexibility or severely limit your options in the future. Take the time to properly evaluate the API management layer that best fits your needs.

Why Open Source is right for your business

This month we feature a guest post by the editor of the excellent API Developer Weekly: James Higginbotham who talks about the benefits of Open Source API Management for your organisation – Take it away James!


Over the last 5 years, we have seen tremendous growth and options available for API management. While some are closed source, many vendors, such as Tyk.io, are choosing to launch as open source API management solutions. Companies are now asking the question, “Is an open source API management layer the right choice?” Let’s examine some of the advantages of open source API management, to help us through the decision-making process.

Advantage #1: Avoid the “DIY” API Management Solution

I have spoken to some groups that have rolled their own API management solution. While your team may be the unique snowflake that needs to build your own API management layer, doing so requires considerable time, resources, and expertise. Instead, start from an open source API management layer.

Dave Koston, VP Engineering for Help.com, agrees: “There’s simply no way we could internally build the feature set of many of the OSS products we use as it would take 10-20 times longer than learning their product and the cost would be many times higher as well.”

A good open source API management layer should offer ways to customize the solution, either via clearly defined APIs or plugin-architecture. Your focus should be on delivering value to the market, not becoming experts in API management.

Advantage #2: Code Reviews Create Confidence

Open source solutions allow the API provider to perform a code and security review – perhaps pairing someone from the API provider with an engineering resource from the vendor. However, Mr. Koston recommends caution when factoring code reviews into your OSS selection: “We reviewed other solutions which were wrapped into other web servers like nginx but having multiple levels of software inside the gateway made it hard to determine where problems arose. Being able to simply read the source of a single product and talk to a single vendor makes the product, and any issues much easier to reason about and deal with.”

Keep in mind that your API management priorities may not be the priorities of some vendors. API management layers must offer a breadth of features. Not every vendor will focus on the ones most important to you. Being confident in the code that is protecting your APIs is important.

Advantage #3: Jumpstarts Your API Management Early

API monitoring and security should start early, not after experiencing growth. Too often, I have seen companies deploy without an API management solution, only to realize that they have no insights into how it is consumed, who is consuming it, and if any security compromises have occurred. The most often cited reason is due to one of limited time, limited/no budget, or uncertainty if the API program will succeed. Once the API program experiences growth, the impact of installing an API management layer is much greater and can have a negative impact on existing API consumers due to changes in account and API token management. Open source API management layers make this an easy and affordable option, even if your API is only used internally or to power web and mobile apps.

What About Technical Support?

When adopting an open source development tool, technical support may vary from Github tickets to mailing lists and Slack groups. However, choosing an open source API management layer doesn’t mean you have to go without vendor support. Many vendors, including Tyk.io, and others offer technical support packages that address the needs of the enterprise, mid-size companies, and growing startups. Be sure to evaluate how your API management layer will be supported long-term as part of your assessment.

Getting Started

Many open source vendors offer distributions of their API management layer that are easy-to-install on a laptop, on-premise, or in the cloud. Start by building a prototype API that mimics your needs, then try out each API management layer to make sure it meets your needs. Your evaluation should include the following considerations:

Authorization – can you implement your desired authorization mechanism (e.g. API tokens, keys, OAuth 2, etc) to meet your needs?

Performance – how much overhead does the layer require for each request? Measure the performance of your API endpoints before and after installing the API management layer. Expect some reduction in performance, but also ensure that the management layer doesn’t cause a drastic decrease in performance that may require additional server capacity

Security – perform some basic penetration testing to verify that the layer is catching common attack vectors. Attacks such as SQL injection, denial of service attack prevention through rate limiting, and other attacks can often be simulated with some simple scripts

Onboarding – how easy or hard will it be for your developers to get onboarded? Does the onboarding process support the business, product, and technical needs of your company?

Reporting – does the management layer provide the information you will need on a day-to-day basis to better serve your developers? Can you export data via an API or push it into an external reporting solution easily, for integration into other daily/weekly reports?

Part of any API program’s responsibility is to select a great API management layer. Make the time to do a proper evaluation to ensure that the one you select will meet the needs of your company.

Tyk joins the Open API Initiative!

Oh frabjous day! This is exciting stuff…

For those of you who don’t know what the OAI is, here’s what they have to say about what APIs represent:

APIs form the connecting glue between modern applications. Nearly every application uses APIs to connect with corporate data sources, third party data services or other applications. Creating an open description format for API services that is vendor neutral, portable and open is critical to accelerating the vision of a truly connected world.

Now, everyone together – what’s the Tyk motto?

Wait, you don’t know it? Shame on you. It’s:

“Connect every system in the world”

Sounds awfully similar amirite?

Bottom line: our goals here at Tyk and the goals of the Open API initiative are very well aligned, as an API Management platform, a lot of the things we end up doing is reading, displaying and interacting with the OpenAPI spec, so it’s very important to us, and our users that we know what’s going on.

We work with a lot of big companies, and we work with a lot of small, fun startups that like to really push the boat out, and every time we see someone talking about another standard, we see the problems caused by the various vendored implementatons (and we’re a vendor!), and by golly, we don’t want to be part of the problem, we want to be part of the solution. Standards make things better – we like standards – and we’re painfully aware of what another standard means to the world of API Description languages:

enter image description here

So we are proud to announce that Tyk is now an official member of the Open API Initiative (OAI) – A Linux foundation collaborative project that is well placed to reduce, rather than proliferate, standards.

The OAI aims to create an open source, technical community where industry participants may easily contribute to and adopt the project’s technology and focus on creating, evolving and promoting a vendor neutral description format currently known as the Swagger Specification.

We are all looking forward to contributing to this project and being a part of reaching our goal.

Tyk 2.2 is Here!

That’s right, the long awaited version 2.2 release is finally here, we’ve been cleaning up, adding features and most importantly, making Tyk easier to use.

The Gateway

Now features some pretty cool new features:

  • OAuth now has support for the client credentials flow
  • It is now possible to use generative security policies with OAuth clients, that means no more needing to send any session data back to Tyk!
  • XML support for inbound and outbound body transforms
  • Context Variables: Get quick and easy access to request data across a variety of middleware, data such as requester IP, form data, headers, path parts and other meta data, all available to the transform middleware
  • Partitioned Policies: Now you can have policies only affect one part of a token instead of all elements, for those who have very complex sales strategies or quota allocation strategies, this makes it much easier to manage. So instead of having to grant ACL, Quota and Rate Limit rules in one go, you can just grant ACL rules, or Quota rules, or both.
  • Normalised URLs in analytics: With this latest update you can normalise the URLs in your analytics to remove those pesky UUIDs and Numeric IDs for more meaningful data


We’ve left this for last, because we’re pretty happy about this, Tyk now transparently supports Websocket proxying as part of your APIs, and these can be protected by the same mechanisms that currently protect your existing APIs, be that Bearer tokens, our Circuit Breaker, or our Load Balancer, the websocket proxy is transparent and will “just work”.

The Dashboard

The dashboard now has a UI for all of the above features, but the biggest change you will find is our new i18n support. That’s right, Tyk Dashboard now has language-pack capability.

To get things started up, we’ve translated the UI into Simplified Chinese and Korean, and have made the language packs available as an open source repository here.

That’s right, it means that it is easy and dynamic to add a new language to Tyk (or to change the wording of the UI if it doesn’t suit you). All of this is configurable and easy to deploy, so have at it.

This update has been a small one for us, because we’re trying to make smaller, more effective releases that help our community and users instead of breaking things. We’ve got some pretty major features in the pipeline coming up, but our real focus will be on stabilising the platform.

As always, Tyk is available on our apt, yum and docker repositories!


Martin & The Tyk Team.

Integrate Tyk with Auth0

There’s been a lot of community chatter about this, and a lot of back-and forth trying to get Auth0 to play nice with Tyk’s low-level JWT handling.

Well, now you can chill, because Auth0 integration is now easy as pie!

Let’s get things ready:

  1. In your Auth0 Application, under OAuth Settings, click “Show Advanced Settings”
  2. Select the “OAuth” tab
  3. Make sure “JsonWebToken Token Signature Algorithm” is set to RS256
  4. Save it

Tyk OpenID Connect Support with RSA Keys

We’re going to simulate a login here, but in a real app, as part of your OAuth flow, you will need to add scope=openid to your authorize request in order to get the OpenID ID Token.

To simulate a login (I assume you have a test user), browse to your “Users” section and click “Sign In As User” and select your App. In order to get the ID Token, you must use the “Client Side App” option.

Tyk Auth0 OpenID Connect Support

When you click this, you’ll be taken to a login page provided by Auth0, you don’t actually need to log in, Auth0 will do that for you. But in the address bar, you will see a query-string parameter called “id_token”, this is your OpenID ID token you are going to try and use with Tyk, copy that token to a file somewhere safe.

Now that we have a token we can play with, we can use it with an API we are proxying with Tyk.

Setting up Auth0 with Tyk

  1. Create a new API, let’s call it auth0
  2. Select “OpenID Connect” as your Authentication mode
  3. Save it.

OIDC with Tyk is a little chicken-and-egg, because we need to apply a set of access rules to users coming in via different clients, so we actually need to create a policy before adding the rules to your API Definition. So now that we’ve saved the API: go create a policy that grants access to it.

Now, back to your Auth0 API Definition:

  1. Add your Auth0 URL as the provider (e.g. https://tyk-test.eu.auth0.com/, each one is different) – in the field that has accounts.google.com as a sample text, and click “Add”
  2. When the new issuer is added, get your Auth0 App’s Client ID and add it as an approved Client ID, and under policies, select the policy you just created.
  3. Click “Add” – you’ll see the policy add to the table
  4. Save the API

Ok, you’re all set – now all you need to do is craft a request to your API using the Authorization: Bearer {id-token} header. You’ll see that the token will get through, and the rate limits / policies will be applied for the user that was requested.

Easy as pie 🙂

Tyk v2.1 is out – Now with Open ID Connect, bug fixes and more!

Recently we announced that we had added full support for Open ID Connect to our Cloud platform, and that we were moving it to our next release in due course.

Well, the wait is over – and as of today it is available to everyone! That’s right, Tyk v2.1 and Tyk Dashboard v1.1 are now available.

This release’s main feature is the OIDC support, however we have also made many improvements and bug fixes, all of which can be seen in the Change Log.

To get started with 2.1 you can just upgrade your existing installations, all the deployment methods are supported and v2.1 will be the default installation for all major distribution methods, but before you go off and do that, please back-up your configuration files!

This is our first attempt at making smaller, more regular releases to ensure that upgrades are easier and involve less risk for you, we dog-food every feature and change in our cloud platform before we cut a version for on-premise installation, so you can be sure that we’ve put all our builds through their paces.


Martin & The Tyk Team

Scroll to top