Skip to main content
A route is a method and a path that the mock answers on. When a request arrives, the mock walks its routes from top to bottom and picks the first one whose method and path match. That route then decides which response to serve. This page covers how the matching works. For the basics of creating a mock and serving your first response, see Mock Server.

​
Method and path

Add a route with the + button above the routes list, then set two things in the response pane at the top:
  • Method: any standard HTTP verb (GET, POST, PUT, DELETE, and so on), plus * to match any method.
  • Path: the path the route answers on, relative to the mock’s base URL. It supports path parameters (:param) and wildcards (*), described below.
Use the filter box above the routes list to find a route by path in a long list, and drag a route up or down to change its order.

​
Path parameters

A path segment written as :name captures whatever appears in that position and exposes it to your response. The captured value is available both in response templates (as urlParam.name) and in matching rules via the URL Param target. For example, a route GET /users/:id with this response body:
serves the captured id straight back to the caller:
A path parameter matches exactly one segment. GET /users/:id matches /users/42 but does not match /users on its own, so a bare /users request finds no route and returns 404:

​
Wildcards

A * in the path matches any characters, including slashes, and captures them as urlParam.0. Pair it with method * to answer every HTTP method on that path. For example, a route with method * and path /static/* and this body:
matches many paths and every method:
The {{request.method}}, {{request.path}}, and {{request.urlParam.0}} placeholders above are dynamic values. See dynamic values for the full list.

​
Ordering and shadowing

Matching is first-match-wins by position: when two routes share the same method and path, the one higher in the list intercepts every request and the one below it is never reached. For example, with two GET /shadow routes where the first returns 200 {"served":"first-route-wins"} and the second returns 500, the first always wins:
The second route’s 500 never appears. The editor flags the shadowed route with a strike-through and a warning icon, with the tooltip “Shadowed by an earlier route with the same method and path - this route is never served”, so you can spot and fix the conflict. Drag the route you want to win to the top, or change one route’s method or path so they no longer collide.
Ordering also drives the Fallback selection mode, where a route that finds no matching response deliberately falls through to the next route that matches the same request. See selection modes.