Do I need an account or an API key?

No. POST /api/mocks is unauthenticated: creating a mock needs nothing but the request itself. Authentication only enters afterwards — the admin token that call returns is what protects editing, deleting and the private inspector of the mock you just created.

How do I delete the mock when the job finishes?

Send DELETE /api/mocks/<slug> with the admin token as a Bearer header. In practice a short ttl_seconds is more reliable, because expiry also cleans up after the jobs that fail or get cancelled before they reach their teardown step.

Can I use the API from a language other than Go?

Yes. It is plain HTTP and JSON, so any client works — the CLI is only a convenience for shells and Makefiles, and nothing in the API depends on it. The API reference lists every endpoint with a runnable curl example.

Public API and CLI

Automate mock generation and test environments using the official CLI tool or direct curl requests.

Creating a mock by hand is fine once. When every CI run, every integration test and every branch preview wants its own throwaway endpoint, you want it scripted. The public API is a single unauthenticated POST that returns a URL and a one-time admin token, and the quickmock CLI is a thin wrapper over that call. Either one turns a mock into something your pipeline creates, uses and discards without anyone opening a browser.

How do you install the CLI?

The CLI is a single Go binary with no runtime dependencies. Install it with the Go toolchain:

go install github.com/Deadsquirrel93/quickmock.dev/cmd/quickmock@latest

That puts a quickmock executable in $(go env GOPATH)/bin. Add that directory to your PATH if it is not there already — a fresh Go installation usually leaves it out, and a command not found immediately after a successful go install is almost always this and nothing else.

There is nothing to install on the server side and no configuration file to write. If you run your own Quickmock instance rather than quickmock.dev, point the CLI at it with -url; every other flag behaves the same.

What does the CLI actually do?

One subcommand does the work. create takes the same fields the API does, as flags:

quickmock create -m POST -s 201 -c application/json \
  -H 'X-Request-Id: abc' \
  -b '{"status":"created"}'

It prints two lines: the public URL of the mock, and its one-time admin token. The URL is what your tests call. The token is what lets you edit, extend, delete or read the private log of that mock afterwards — it is shown exactly once and cannot be recovered, so capture it in the same step that creates the mock rather than in a later one.

Repeat -H for each response header you want, exactly as you would with curl. A value without a colon is rejected rather than ignored, so a typo fails the step instead of quietly producing a mock that is missing a header.

How do you create a mock from a pipeline?

In a pipeline the CLI is often one dependency too many, and the API is a single request. Create the mock in a setup step, hand the URL to whatever runs next, and let the TTL clean up after you:

MOCK=$(curl -s -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{"method":"GET","response_status":200,"ttl_seconds":3600}')
echo "MOCK_URL=$(echo "$MOCK" | jq -r .url)" >> "$GITHUB_ENV"

Set ttl_seconds close to how long the job actually runs. A mock created with a one-hour TTL disappears on its own, which means a cancelled or failed job leaves nothing behind and you never need a teardown step that might not run.

Keep the admin token out of the log while you are at it. curl -s piped through jq -r .url prints only the URL; echoing the whole response body writes a working credential into a build log that anyone with access to the project can read.

What usually goes wrong?

Discarding the admin token. It appears in the create response and nowhere else. Without it you cannot edit, delete or read the private logs of that mock — you can only wait for it to expire.
One mock per test case. The limit on active mocks per IP is real, and a CI runner is a single IP. Create one mock per job and use named variants or routes for the different cases.
Hardcoding the slug. Slugs are assigned, not chosen. Read the url field out of the response and pass that along.
No TTL. Without ttl_seconds the mock lives at the server default, long after the job that needed it has finished.

When to use this

Manual creation is fine for quick prototyping, but CI/CD pipelines and automated tests require reproducible, dynamic environments. The Public API and CLI allow you to script the creation, modification, and teardown of mock endpoints on the fly, feeding the generated URLs directly into your test suites.

Create the mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 201,
  "response_body": "{\"status\":\"created\"}"
}'

Call it

curl -X POST https://quickmock.dev/m/<slug>

What you get

{"status":"created"}

FAQ

Do I need an account or an API key?: No. POST /api/mocks is unauthenticated: creating a mock needs nothing but the request itself. Authentication only enters afterwards — the admin token that call returns is what protects editing, deleting and the private inspector of the mock you just created.
How do I delete the mock when the job finishes?: Send DELETE /api/mocks/<slug> with the admin token as a Bearer header. In practice a short ttl_seconds is more reliable, because expiry also cleans up after the jobs that fail or get cancelled before they reach their teardown step.
Can I use the API from a language other than Go?: Yes. It is plain HTTP and JSON, so any client works — the CLI is only a convenience for shells and Makefiles, and nothing in the API depends on it. The API reference lists every endpoint with a runnable curl example.

Build your own

Create a mock

Related guides

← All guides

Last updated: 2026-10-17