Record routes and watch calls#

Two features help you fill and watch a mock server. The journal shows every request that hits the mock and how the mock handled it. Recording builds routes for you from a real upstream. Together they turn a live API into a set of mock routes, and they show you what your client asks for.

Read the journal#

Every incoming request appears in the journal as a row with its time, status, method, path, latency, and tags, newest first. The journal holds the most recent 500 requests. Select Clear to empty it.

The journal is the fastest way to see what your client actually sends. That is often not what you expected. Select a row to see the match trace: which condition ran, what it expected, what the request carried, and whether it passed. When a request matched on method and path alone, the row says so. The trace also makes it clear why a request fell through to a 404. The cause is usually a condition that did not match.

Fallthrough#

Fallthrough decides what happens to a request that matches no route. The default is a 404. The other choice is a proxy to an upstream URL, which you supply when you pick that option. A proxy lets the mock stand in front of a real API. The mock answers only the routes you defined and passes the rest through.

Recording routes from an upstream#

Recording turns unmatched traffic into routes. It is off by default. Set it to record missing. The mock then forwards a request that matches no route to the upstream, and saves the reply as a new route. Send your app's real traffic through the mock once. You come away with a route for each call, ready to edit and replay offline.

In the journal, these requests carry a tag. The tag tells you which replies came from the upstream and which ones came from a saved route. Recording needs an upstream to forward to, so use it with the proxy fallthrough above.