Skip to main content
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.

​
The Request Journey

Flowchart showing the decision tree taken by Tyk's request routing algorithm 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 the tyk:// 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.

​
Protocol Support

The stages above apply to all traffic Tyk handles. Where behavior differs for gRPC, WebSocket, Server-Sent Events, or TCP traffic, the relevant page notes the difference.