Setting up multiple API's with different listen paths

Hi, all.

We have used tyk for sometime and initially just had one API defined. Now we have a need to have two different versions of API up and running. On the background this is handled by running two processes with different configurations and on different ports.

As our API is running on different ports, we cannot use tyk support for specifying API versions as the target URL of the defined API should be different, depending on which port tyk needs to forward the request.

I have tested setting up different API’s for that and specifying different listen paths for different versions. This works great in case I have two API’s one listening on path “/v1/” and the other listening on path “/v2/”. Now I also wish to setup third API, which would be the default un-versioned one, so listening on path “/”.

I have not been able to get those three to work together as when I specify the third default API all the requests are captured by this API, causing some requests to end up in the wrong target URL.

Should this be possible at all to have those three working together? If yes, could you give me some guidelines on how to achieve this?

Best regards.


Hi Piret,

I’d recommend not using URL-based versions, and use headers instead, that way all your APIs live on / and can be targeted using version headers.

However, you run into a problem with the listen paths, as you describe.

On the develop branch, we’ve introduced multi-target versioning where you can specify a different override host per version, so you could build the develop branch and get your hands on that (should be a drop-in replacement).

There’s a hidden feature you could currently use that might help, if you are using dashboard, you can add a sort_by: x integer value to the root of the object (either directly in the DB or using the API), this will force the APIs to load in the order you set them in the sort_by value, so you can have the v1/ and v2/ paths load first into the route muxer and be evaluated before the default.


Hi, Martin.

Thank you for a fast response.

Setting the sort_by value in API definitions helped to achieve the needed result.

Best regards.