FlowMock

Mocks and overrides

Swap any API response for your session — without touching staging.

On this page

A mock (we call it an override in the API) replaces what your app receives for a specific request. Need GET /api/cart to return an empty cart? Create a mock. Need POST /api/pay to return a 402? Same idea.

By default, mocks only apply to your session. Staging keeps humming along for everyone else.

The mock library

Each environment has a mock library — a collection of reusable response overrides. Think of it as a menu of test states you can pick from:

  • Empty cart
  • Payment declined
  • Server error on checkout
  • Slow shipping quote

Create mocks once, activate them per session whenever you need them.

Matchers

Mocks match requests by:

  • HTTP method — GET, POST, PUT, etc.
  • Path — /api/cart, /api/users/:id
  • Query parameters — optional, for finer matching
  • Request body — optional, for POST/PUT matching

More specific matchers win over generic ones. A mock for POST /api/pay with body { "amount": 0 } beats a mock for POST /api/pay alone.

Drafts vs published

Mocks start as drafts — visible only to you, safe to experiment with. When you're happy, publish the mock to make it available for session activation.

StateWho sees itCan activate?
DraftJust youNo (drafts are for editing)
PublishedWhole teamYes, per session

Activating mocks

Once published, activate a mock for your session:

  1. Dashboard — Sessions tab → pick a session → toggle mocks on
  2. Scenario — bundle mocks into a preset and switch the whole set at once
  3. Public API — PUT /sessions/:key with an overrides array, or toggle individually

Mocks stack with your active scenario. Session-specific activations layer on top.

Response types

A mock can:

  • Return a fixed JSON body with a chosen status code
  • Return headers alongside the body
  • Add a delay before responding (great for loading states)

Transforms (reshaping upstream responses) are a separate feature — mocks fully replace the response.

Tips for good mocks

  • Name them clearly — "Payment declined (402)" beats "mock 7"
  • Start specific — narrow matchers reduce accidental matches
  • Publish when stable — drafts are for iteration, published mocks are for the team
  • Use scenarios for bundles — don't manually toggle five mocks every time