API Gateway Service en

Cloud users: If you are a paying customer and you don’t use webhooks then you would need to contact us and we will set this up for you. On-Premises users: You can set this up using alerts and webhooks.

For security reasons Tyk lowercases the URL before performing any pattern matching.

We do not allow third party code to run in our shared infrastructure (Tyk Cloud Classic), however you can use Virtual Endpoints if you are a Multi-Cloud or On-Premises user.

Use case: What if your developer portal is not exactly what I need? Sometimes our Tyk Gateway won’t suit your exact needs. Maybe you want to combine multiple Tyk installations under the same portal, or use your existing portal and add our functionality, or maybe white label the portal per organisation? We have the ability to configure the portal to suit your needs. For details, including a video tutorial, see Create a Custom Developer Portal.

Tyk Gateway is not able to get API configs from the Tyk Portal. If you configured your Gateway to be segmented, you would also need to assign tags and you must also tag the APIs in the API Designer to make sure that they load. In the Pro edition that is a connectivity or misconfiguration issue In the Community edition, since you are not using the Dashboard we assume that you use file-based APIs , so in this case it’s because API definition files are missing.

It’s not possible to segregate out the error locations in the tyk.conf, but you can modify the actual initialisation files to specify the log location, we supply initialisation scripts for SysV, systemd and upstart.

Websockets are enabled by default in our Cloud environment.

Open the Active Policies page in the Dashboard (System Management > Policies) and click Edit next to the name of the policy you’ve created. The policy ID should appear in the URL of the edit page that opens up.

Unfortunately its not possible to run the Dashboard and Portal on different ports, they must use the same port.

Information relating to a given key doesn’t automatically appear in the Dashboard for users who have switched from an On-Premises installation to a Multi-Cloud setup. The stats for a key will never update in the Cloud for a Multi-Cloud installation. The Dashboard in this mode only sets the initial “master” values for a key and those keys are then propagated across the Multi-Cloud instances that are using them (for example, you may have multiple zones with independent Redis DBs) at which point they diverge from each other. To see the up to date stats for a token, the key must be queried via the Gateway API./p>

Use case: Keep my data persistent at Docker container restart The Multi-Cloud Redis container is ephemeral, it isn’t configured for persistence because it would very quickly get very large (Docker containers in general should really be considered as ephemeral). If using Redis with Multi-Cloud we strongly recommend using an external Redis database. There are no settings for Redis available via environment variable, you would need to mount a new redis.conf into the container to customise the configuration, but again, we don’t recommend it.