A free mock API server built from your saved examples

A mock API server answers HTTP requests with canned responses, so a frontend, a mobile app or a test suite can work before the real backend exists, or while it is down. In Swastik Codes, a mock server is built from the saved examples in a collection: each example is a response for a request, and the mock serves the best matching one at a public URL such as https://swastik.codes/api/mock/<mock-id>/users/42.

Mock servers are free to use. This guide shows how to create one, how requests are matched to examples, how to force a specific response with x-mock-* headers, how to make responses dynamic with templates, and how to keep a mock private.

How it works in one paragraph

You have a collection with requests such as GET {{baseUrl}}/users/:id. Each request can have saved examples: a status code, headers and a body, plus the request that produced them. When a call arrives at the mock URL, the server looks for requests with the same method and path (:id and {{variables}} in the path act as wildcards), scores their examples on query parameters, headers and body, and returns the best one. If nothing matches, it answers 404 with the error code mock_request_not_found.

Step 1: create a collection with examples

Open the app and create a free account. Mock servers with a public URL live in cloud workspaces, so you need to be signed in. (You can also create a local mock that lives on your device and answers only inside the app, which is enough to try the matching rules.)

Create a collection called "Users API" and add a request:

GET {{baseUrl}}/users/:id

There are two ways to give it an example:

1. From a real response. Send the request to a real API and click Save as example above the response. The status, headers and body are saved.
2. By hand. Once the mock exists, its Examples tab lists every request in the collection. Click Add example next to a request and fill in the name, status code, status text, response headers and body.

Here is an example body for a 200 OK response:

{
  "id": 42,
  "name": "Asha Rao",
  "email": "asha@example.com",
  "plan": "team"
}

Add a second example to the same request with status 404 and a body like {"error": "user not found"}. Having both lets you test the "not found" path of your client later.

You can also import an existing collection. Postman collections with saved examples, HAR files (every captured response becomes an example) and OpenAPI specs with examples all give you a mock-ready collection in one step. See How to import a Postman collection.

Step 2: create the mock server

Click New in the top bar and choose New mock server. The dialog asks for:

• Collection: the collection whose examples will be served. The dialog previews the routes that will be served, with the number of examples and status codes for each, and lists requests that have no examples (and so will not be served).
• Name: defaults to "<collection> mock".
• Environment: optional. Its variables resolve {{variables}} inside examples.
• Simulated network delay: none, 300 ms, 800 ms, 2 s or a custom value.
• Private: callers must send an x-api-key header with one of your API keys.

After you create it, the mock's Overview tab shows its URL with a Copy button and a ready-made curl command.

Step 3: call it

The mock URL is the root of your API. Append the path that the request uses after its base URL:

curl -i https://swastik.codes/api/mock/<mock-id>/users/42

The path in the saved request is {{baseUrl}}/users/:id, so /users/42, /users/7 and /users/abc all match. You get the 200 example back, with the status and headers you saved.

The mock answers CORS requests from any origin, so you can call it from a frontend running on localhost:5173 without any proxy:

const res = await fetch(
  "https://swastik.codes/api/mock/<mock-id>/users/42"
);
console.log(res.status, await res.json());

Request bodies sent to a mock can be up to 1 MiB.

Choosing a response with x-mock-* headers

When a request has several examples, the scoring picks the closest one. When you want a specific response, for example to test how your app handles errors, send one of these headers:

curl -i https://swastik.codes/api/mock/<mock-id>/users/42 \
  -H "x-mock-response-code: 404"

The x-mock-* headers themselves never take part in matching.

Strict matching as a setting

Body and header matching can also be switched on for the whole mock in its Overview tab under Response matching: tick Match request body and/or Match request headers and list the header names. JSON bodies are compared structurally, so key order and whitespace do not matter. This is useful for a POST /login that should return 200 for the right credentials and 401 for anything else: save one example per case and turn on body matching.

Dynamic responses with templates

A static example gets you far, but sometimes the response should echo the request. Example bodies and header values support template helpers that read from the incoming call:

The second argument is the default when the value is missing. Strings are inserted as plain text (so put quotes around them in a JSON body), numbers and booleans as written, and objects and arrays as JSON.

For GET /users/:id, this example body returns whatever id was asked for:

{
  "id": "{{$pathSegments '1'}}",
  "name": "Asha Rao",
  "requestedAt": "{{$timestamp}}"
}

/users/42 gives "id": "42". Path segments are counted after the mock root, so segment 0 is users and segment 1 is the id.

For a POST /orders that should echo what was sent:

{
  "orderId": "{{$guid}}",
  "sku": "{{$body 'items[0].sku' 'unknown'}}",
  "quantity": {{$body 'items[0].quantity' '1'}},
  "status": "received"
}

Two kinds of substitution happen, in order. First {{variables}} are resolved from the collection variables and the mock's environment, together with dynamic variables such as {{$guid}}, {{$timestamp}} and {{$randomInt}}. Then the request helpers run. Because helpers run last, text copied from the incoming request is never itself treated as a variable.

Private mocks

By default anyone with the URL can call a mock. Tick Private to require an API key: callers send x-api-key: swc_... with a key belonging to someone who has access to the workspace. Calls without a valid key get 401 or 403. Create keys in your account settings; each key is shown once when created.

curl https://swastik.codes/api/mock/<mock-id>/users/42 \
  -H "x-api-key: $SWC_API_KEY"

The call log

The Call log tab shows the last 100 calls to the mock: method, path, query, status, which example answered, request headers, request body and how long it took. You can filter by path, method and status. Sensitive headers (Authorization, Cookie, X-Api-Key and Proxy-Authorization) are stored as [redacted].

The call log is the quickest way to debug "why did I get a 404": you can see the exact path and headers the mock received and compare them with the saved request.

The Try it tab sends calls to the mock from inside the app, which is handy when you want to check a template without leaving the browser.

Troubleshooting

404 mock_request_not_found. No request in the collection has the same method and path, or strict matching filtered every example out. Check the call log for the exact path, and check that the request has at least one example. Remember that the path is matched after the base URL: for {{baseUrl}}/v1/users, call /v1/users on the mock.

The wrong example answers. Add x-mock-response-name or x-mock-response-code, or give the examples' saved requests distinguishing query parameters or headers so scoring can tell them apart.

{{baseUrl}} appears in the response. The example uses a variable that is defined neither in the collection nor in the mock's environment. Pick an environment in the mock settings or add a collection variable.

A template prints the default. The path, field or header name does not exist in the incoming request. Header names are case-insensitive; JSON paths are case-sensitive.

Frequently asked questions

Is the mock server free?

Yes. Swastik Codes is free to use today, including mock servers.

Can I mock an API from an OpenAPI spec?

Yes. Import the spec (or design it with the API design tools) to generate a collection; operations that have examples in the spec get saved examples you can serve.

Does the mock support GraphQL or WebSocket?

The mock server answers HTTP requests from saved examples. A GraphQL query sent as an HTTP POST can be mocked like any other request, using body matching to tell queries apart. WebSocket and other streaming protocols are not mocked.

Can I use the mock from a browser app on localhost?

Yes. Mocks allow requests from any origin, so a local frontend can call the mock URL directly.

How many calls are logged?

The last 100 calls per mock, with secrets redacted.

Start mocking

Open the app, create a free account, save a couple of examples and click New mock server. The mock server feature page summarises everything above, and once the real API exists you can point the same collection at it and check it with pm.* tests.