Mock API Builder (Endpoints & Mock Server)

About the Mock API Builder (Endpoints & Mock Server)

Design a mock API without writing a server or a specification. Each route has a method and a path with parameters (/users/:id), and one or more responses with a status, headers, a delay and a body. Pick a response by rules on the query string, a header, a path parameter or a field of the JSON body, in sequence (first call, second call …) or at random by weight. Bodies are templates: {{params.id}}, {{query.page}}, {{headers.user-agent}}, {{body.email}} and fake values such as {{faker.person.fullName}} or {{faker.string.uuid}} are filled in for every request — by a logic-less template language, so nothing in a template is ever run as code. Collections add create, read, update and delete endpoints that keep their records in memory.

Try every route in the page with the built-in tester: it shows the reply, its headers and delay, and which route and rule answered. Requests in the tester never leave the page, and nothing is hosted anywhere. Bring routes in from an OpenAPI or Swagger file, a HAR capture from your browser, a Postman collection or a Mockoon environment; with a Premium pass, export a runnable mock: a Mockoon environment, MSW handlers for tests and front ends, a json-server db.json, a Node/Express server, a FastAPI app or WireMock mappings.

Without a pass the result is a free preview: your first 3 routes are built and tried in full and every check shows; the exports show their first lines, and more routes and copying or downloading the files unlock with a Premium pass.

Common uses

• Building a front end before the back end exists, against endpoints that answer like the real ones.
• Giving tests stable, offline responses with MSW handlers, WireMock stubs or a json-server file.
• Reproducing an error, a slow response or a flaky endpoint to test retries and loading states.
• Turning a HAR capture or a Postman collection into a mock you can run on your own machine.
• Demonstrating an API design to a team before anyone writes the server.

How a request is answered

Routes are tried from the top: the first whose method (or ANY) and path match answers, then the collections. A path such as /users/:id matches one part for each parameter; * at the end matches the rest of the path, which {{params.*}} fills in. Within a route, rules pick the first response whose conditions hold (all of them, or any of them); a response without rules always holds, so it belongs last. Sequence answers with the responses in turn, and random by their weights. A request that matches no route gets a 404, and with CORS on, a browser’s preflight is answered and every reply allows any origin.

Templates

• {{params.name}}, {{query.name}} (the first value), {{headers.name}} (any case) and {{body.path.to.field}} (positions too: {{body.items.0.sku}}; {{body}} is the whole body) read the request.
• {{method}}, {{path}} and {{now}} (an ISO 8601 time) describe it.
• {{faker.namespace.method}} fills in a value from Faker, the open-source fake-data library: names, e-mail addresses, UUIDs, addresses, prices and more; the list is under Template help.

When the response’s Content-Type is JSON, a placeholder inside quotes is escaped and one outside quotes is written as a JSON value, so the reply stays valid JSON. Anything else between double braces is left as written, with a warning.

What each export carries

• Mockoon: an environment file to open in Mockoon or run with its command-line interface, with the routes, rules, sequences, collections (as data buckets) and templates in Mockoon’s own helpers (Mockoon templating); random picks there are even, not weighted.
• MSW: request handlers for MSW 3 (from msw/http) or 2, in TypeScript or JavaScript, with a small copy of this page’s engine so they answer as the tester does.
• json-server: a db.json of the collections for json-server, which has no custom routes.
• Node / Express: a one-file Express 5 server.
• FastAPI: a one-file Python app; Faker values come from Python’s Faker where it has the same kind of value.
• WireMock: stub mappings for the WireMock import endpoint, with response templating, priorities for rules and scenarios for sequences; collections become read-only stubs and Faker values fixed samples.

Importing

OpenAPI 3 and Swagger 2 (JSON or YAML) give one route per operation, with the example or a body made from the schema; the other documented responses answer when the request sends X-Mock-Status: 404 (or that response’s code). A HAR capture from a browser’s network panel gives one route per method and path — numbers and IDs in paths can become parameters — replaying different captured answers in sequence. A Postman collection (v2.1) gives its requests with their saved example responses, and a Mockoon environment its routes, rules, collections and the helpers this page fills in.

Limitations

• The mock runs in this page and in the files you export; the page itself hosts nothing, so other devices and apps reach your mock only through an export you run.
• Templates have no conditions or loops: for logic, pick responses with rules, or edit the exported code.
• Collections answer only simple filters (?done=true); paging and sorting are not mocked.
• Imports read what each format describes plainly: OpenAPI callbacks and links, HAR WebSocket frames and Postman scripts are left out.
• The free preview builds and tries the first 3 routes; collections count after them.

Privacy

On this device; its files download once

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot. Fake values ({{faker.…}}) need Faker, which loads from MySmartCoPilot the first time a template uses one; your routes and requests stay in this browser.