Tyk Gateway sits between clients and upstream services, receiving every API request and deciding where it goes. This section covers the mechanisms that control those decisions: how Tyk identifies which API and endpoint owns a request, where it sends the matched request, and what happens when the standard request-response flow needs to be modified or bypassed.Documentation Index
Fetch the complete documentation index at: https://tyk.io/docs/llms.txt
Use this file to discover all available pages before exploring further.
The Request Journey
DIAGRAM REQUEST: “The Tyk Request Journey” A request arriving at Tyk passes through a sequence of routing stages. Matching: Tyk compares the incoming request against all configured APIs to find the one whose listen path matches the request URL. Within that API, it identifies the endpoint whose path pattern matches. No further processing occurs until a match is found. Forwarding: Tyk forwards the matched request to the configured upstream target. Where multiple targets are configured, load balancing distributes traffic across them. Where upstream addresses are dynamic, service discovery resolves the current target at request time. Path Modification: Before forwarding, the request path can be rewritten. This handles cases where the path a client sends differs from the path the upstream expects, or where request content should determine the destination. Internal Routing: Rather than forwarding to an external upstream, a request can be routed to another API or endpoint within the same Tyk instance using thetyk:// addressing scheme. This enables multi-step processing pipelines that stay
entirely inside the gateway.
Request Termination: Some requests are handled entirely by the gateway and never reach an upstream. A mock response, for
example, returns a pre-configured static payload directly to the client.