Mock Server
A full HTTP mock server lives inside Tigrister. You can spin up a local server on any port, define endpoints with their own method, path, request body, response body, headers, status code, and delay, and then start or stop the server with a single button — without installing a separate tool, writing a config file, or leaving the app.
What the Mock Server Is For
A mock server replaces a real backend with a fake one you fully control. You decide what every endpoint returns, how long it takes to answer, and which response is served when the incoming request matches a specific condition. A few common situations where this is useful:
- •Frontend ahead of backend: the API is not ready yet, but you still need realistic responses to build the UI against.
- •Third-party bypass: the real service is slow, flaky, rate-limited, or costs money per call — you prefer a fast local replica for day-to-day work.
- •Edge-case rehearsal: you need to see how your client behaves against a 500, a timeout, an empty array, or a malformed payload — cases that are hard to reproduce against a real server.
- •Demo and teaching: you want a predictable server you can point a workshop, a screenshot, or a customer demo at.
What You Can Control
Each endpoint in the mock server is fully described by a handful of fields. Everything listed below is editable from the panel — no file editing, no restart required between edits while the server is running:
- •Method and path: any standard HTTP method and any path that begins with a forward slash.
- •Request body variants: one or more request bodies, each with its own content type, used for documentation and optional body matching.
- •Query parameters and request headers: key-value rows you can enable, disable, or edit individually.
- •Response variants: one or more response bodies, each with its own content type. Exactly one variant is marked as the default; the others are picked by rules.
- •Rules: per-variant conditions on the incoming body, a JSON path inside the body, or a request header. If the rules match, that variant is the one returned.
- •Status code and delay: any HTTP status between 100 and 599 and any delay in milliseconds.
- •Response headers: custom headers plus an auto-generated Content-Type that follows the chosen body type.
What This Chapter Covers
The sub-sections below walk through the mock panel from the first moment you open it to the moment a running server is answering requests on a local port. They are ordered to match the natural flow of building a mock: open the panel, create a server, add endpoints, describe the request, describe the response, add rules if you need branching, then start the server.
- •Getting in: Opening the Panel, Creating a Server, Server List Sidebar, Server Header & Start/Stop.
- •Shaping an endpoint: Endpoint Tabs, Method & Path, Request Panel, Response Panel.
- •Branching behaviour: Response Variants & Default, Rules — Conditional Responses, Status & Delay, Headers.
- •Bonus: Body Preview & Random Variables, Best Practices.