Changes apply to the next request
Edit a response, switch to a different one, add a delay. The next request uses it. There is no restart and nothing to reload.
01OverviewChapter 01 of 08
Control your app’s HTTP responses and build repeatable scenarios for failures, retries, timeouts, and edge cases. Run them from the CLI, your test suite, or an AI coding agent.
- Requires
- macOS 26.0 or later
- Runs on
- Apple silicon and Intel
- Installer
- about 52 MB
- Price
- Free, no account
Nothing has arrived yet. Send a request below.
Send
Press the request marked next four times. GET /account-summary is step 2 and step 4, so it answers 500 and then 200.
02The modelChapter 02 of 08
- Endpoint
- A method and a path your app calls. Mimic matches each request to one of these, and lists the ones it could not match so you can see what is still missing.
- Response
- What goes back: a status code, headers, a body. One endpoint can hold several, and you switch between them while your app keeps running.
- Journey
- Those responses in order, so the same endpoint answers 500 on the first call and 200 on the retry. 9 journeys are included.
GET/orders/:id
200application/json
500200
Most mock servers answer every call to an endpoint the same way, which leaves the retry, the expired session and the timeout untested. A journey is a list of responses in order, and Mimic serves them one per matching request. Nine come with the app.
Journeys9 included · 2 of 4 served
- Retry after failure
- Payment retry
- Expired session
- Two-factor prompt
- Maintenance window
- Loading in stages
- Offline and back online
- Feature flags
- Edge cases
- Match
- Ordered per route
- On completion
- Stop
- Unscripted
- Fall through
- 1POST/login200
- 2GET/account-summary500
- 3GET/inbox200
- 4GET/account-summary200
The same journey, without the appzsh
# the journey the console above is running mimic journey add-template retry-after-failure --activate mimic server start API=localhost:8080 curl -X POST $API/login → 200 curl $API/account-summary → 500 first load fails curl $API/inbox → 200 user moves on curl $API/account-summary → 200 retry succeeds
Steps answer in order
Each step answers one request. The same URL can return 500 the first time and 200 the second, and a step can repeat if the same request happens several times.
A step can fail like a bad network
Instead of returning a status code, a step can drop the connection or never respond at all. That covers what your app does when the network itself fails.
Requests you did not list still work
A request that is not in the journey is answered from your normal endpoints, so you only have to list the ones you care about.
Restart it, or move it on by hand
The controls above the steps deactivate the journey, send the cursor back to step one, or move it on a step. A test does the same thing with one command between cases.
Recording
Point your app at Mimic and use it normally. Then select the requests you want from the log at the bottom, right-click, and save them as a journey.
Saved in the order they happened
Sorting the log by status code to find the failure does not change the order of what you save.
Repeated requests become one step
Six identical 202 responses before a 200 turn into one step that repeats six times.
Only the response is saved
A step stores what Mimic sent back. Whatever your app put in its request headers is not copied into it.
Create an endpoint, change a response, start a journey, read back the requests that arrived. A coding agent told to mock the checkout API and test a failed payment can set that up, run it and read the result. Your test suite drives it the same way.
Command lineprints JSON
# keep test data out of your own projects export MIMIC_DATABASE_PATH="$PWD/.mimic-ci/store.sqlite" mimic daemon start # no window mimic project import fixtures/api.json mimic journey activate "Session expiry" mimic reset --scope all # back to step 1 # … run your tests here … mimic journey status | jq -e '.journeyStatus.isComplete'
HTTPfor anything that is not a shell
# the mimic command just calls this, so anything can H="X-Mimic-Token: $TOKEN" curl -s -H "$H" \ 127.0.0.1:8787/v1/commands # what this build accepts curl -s -X POST 127.0.0.1:8787/v1/command \ -H "$H" \ -d '{"journeyActivate":{"journey":{"name":"Session expiry"}}}'
It tells you what it accepts
Ask a running copy of Mimic for its list of commands and it sends one back. An agent that has never seen this version can find out what is available instead of guessing at flags.
It answers in JSON, so a test can check it
Which requests arrived, what was returned, whether a journey finished. A test can assert on that, and an agent can check its own work without asking you to look at the screen.
It is reachable only from your Mac
This interface listens on 127.0.0.1 and nowhere else, and it requires a token that changes every time Mimic starts.
Endpoints on the left, the response you are editing in the middle, its other responses on the right, and the request log along the bottom filling up as your app runs. You can change a response and watch the next request pick it up without leaving this screen.
Endpoints
Grouped by tag, with the one being edited selected.
The response
Status code, headers and body, edited in place.
Its other responses
The app calls them scenarios. One is active at a time.
The request log
Everything that arrived, and what answered it.
Editing
Scenarios
Several responses per endpoint
Keep a success, an error and an empty response on the same endpoint, and switch between them while your app is running.
Request log
See what your app actually asked for
Every request is listed, including ones nothing is set up for. Those are marked Unmatched, so you can see which endpoints you still need.
Inspector
Open a request to read it
Click a request to see what was sent and what came back: headers and body, formatted and searchable.
- Import
- A HAR file saved from your browser, or an OpenAPI or Swagger document, turned into endpoints you can review and edit before keeping them.
- GraphQL
- Matched on the operation rather than the path, because GraphQL sends everything to one URL. Still works when the client sends no operation name.
- Path parameters
- /orders/:id matches any order. Define /orders/new as well and the exact one wins.
- Delays
- Per endpoint, and one project-wide delay added on top of it. You can test loading states and timeouts without changing your app.
- Response headers
- Set your own on any response, alongside the status code and the body.
- Group tags
- Endpoints are filed under a tag you choose, which is how the sidebar is ordered.
- Unmatched requests
- A request no endpoint covers still appears in the log, marked Unmatched, so you can see what you have not set up yet.
- Reset
- One command returns every journey to its first step and clears the log. Tests run it between cases.
- The port
- localhost:8080 out of the box, and the server only ever listens on your own machine.
How is this different from the mock server I already have?
Most of them can return a different response each time, usually by declaring states and the transitions between them. Here a journey is a list. You write the responses in the order they happen, or you use your app, pick the requests out of the log, and save them as a journey.
Does it work with my test framework?
Mimic is an HTTP server on localhost:8080, so anything that can make a request can use it. There is no plugin and no adapter to install. Between cases your tests run mimic reset, which returns every journey to its first step and clears the log.
Can I use it without opening the app?
Yes. Every action in the window is also a command and an HTTP call, and both answer in JSON. A test suite or a coding agent can set up endpoints, switch responses, run a journey and read back what arrived. The app does not have to be in front of you.
What does it cost?
Nothing. There is no account and no trial period, so there is nothing to cancel either. Download the installer and use it.
How finished is it?
It is an early release, numbered below 1.0. Everything described on this page works today, and the app is still changing.
Can I run it on an older macOS?
No. macOS 26.0 is the minimum and the installer will not run on anything earlier. It works on both Apple silicon and Intel Macs.
Where does my data go?
Nowhere. Projects are files on your Mac. The mock server listens only on your own machine, and the interface the command line and agents drive is bound to 127.0.0.1 behind a token that changes every time Mimic starts.
What if my API is GraphQL, or I already have an OpenAPI document?
GraphQL is matched on the operation rather than the path, because GraphQL sends everything to one URL. An OpenAPI or Swagger document, or a HAR file saved from your browser, imports as endpoints you can review and edit before keeping them.
Install it, activate one of the included journeys, and point your app at localhost:8080.
Mimic for macOSabout 52 MB · Apple silicon and Intel · macOS 26.0 or later
Download the installerInstalling itzsh
# double-click the installer, or from a terminal: sudo installer -pkg ~/Downloads/Mimic-*.pkg -target / # Mimic.app lands in /Applications, the mimic command in # /usr/local/bin. Nothing else to move. mimic --version # check it is on your PATH
What you get
- Price
- FreeNo account and no trial period.
- Requires
- macOS 26.0 or laterEarlier versions of macOS are not supported.
- Works on
- Apple silicon and Intel
- Your data
- Stays on your MacProjects are saved locally, and the servers only listen on your own machine.
- First launch
- Nothing to approveSigned and notarised by Apple, so macOS opens it without warning.
- Release
- Early, and numbered below 1.0Everything described on this page works today. The app is still changing.
- What it installs
- The app and the mimic commandMimic.app in Applications and mimic in /usr/local/bin, in one step. The command is optional to use but always installed.