A mock API for VS Code REST Client: one curl gives you the backend and the .http file to drive it

The humble .http file is the lightest API client there is. Plain text. Lives in your repo next to the code that calls the API. Diffs in pull requests. No account, no cloud sync, no workspace to import. In VS Code you install the REST Client extension (humao.rest-client) and click Send Request; in IntelliJ, WebStorm, or PyCharm the HTTP Client is already built in — just open the file.

The catch: someone has to write the file. And if you're using one to explore an API that doesn't exist yet — the backend your team hasn't built, the schema you're still designing — you have to write the API too.

Mockbird does both in one curl. Every mock project serves a generated, ready-to-run requests.http for its own live schema.

Try it in 10 seconds (no signup)

curl -o requests.http "https://mockbird.mockbird.workers.dev/m/demo/requests.http"
code requests.http     # or open it in any JetBrains IDE

That's the public demo project — a seeded e-commerce backend (products, orders, customers, reviews) anyone can hit. The file you get back contains a request block for every operation, with example bodies that match each field's type:

@baseUrl = https://mockbird.mockbird.workers.dev/m/demo

### List products (paginated; total count in x-total-count header)
GET {{baseUrl}}/products?page=1&limit=10

### Create a product (persists — run the list request again to see it)
POST {{baseUrl}}/products
Content-Type: application/json

{
  "name": "Silver Mountain Road",
  "price": 19.99,
  "category": "electronics",
  "inStock": true,
  "rating": 4.5
}

### Simulate a 500 from the API (mock_status forces any 400-599)
GET {{baseUrl}}/products?mock_status=500

### Simulate a slow response (2s; mock_delay is in ms, max 5000)
GET {{baseUrl}}/products?mock_delay=2000&limit=3

Click Send Request above the POST, then re-run the list request: the record is there. Writes persist — this is a real (mock) backend, not canned responses. The last two blocks are failure drills: force any status code or a slow response to see exactly how your tooling behaves.

Get a .http file for your schema

Create a project (one curl, anonymous, claim it later if you want):

curl -X POST https://mockbird.mockbird.workers.dev/api/projects \
  -H 'content-type: application/json' \
  -d '{"name":"my api","preset":"ecommerce"}'
# → { "id": "abc123def4", "adminKey": "...", ... }

curl -o requests.http "https://mockbird.mockbird.workers.dev/m/abc123def4/requests.http"

Prefer a UI? This link creates a seeded project in the dashboard in one click — the requests.http ↗ link is right next to the project URL. And the schema doesn't have to be a preset: import an OpenAPI spec, a json-server db.json, a CSV, a Postman collection, or a HAR file and the generated .http file covers your exact resources.

Changed the schema? Just re-curl. The file is generated from the live schema on every request, so it can't drift the way a hand-written one does.

Auth is pre-wired (protected mode)

If you flip a project to protected mode (every request needs a Bearer token — great for testing 401 handling), the generated file starts with a named login request and every later request references its response:

# @name login
POST {{baseUrl}}/auth/login
Content-Type: application/json

{ "email": "you@example.com", "password": "anything" }

### List products
GET {{baseUrl}}/products?page=1&limit=10
Authorization: Bearer {{login.response.body.$.token}}

In VS Code REST Client you run the login once and every subsequent request resolves the token automatically. (The {{login.response.body.$.token}} response-reference syntax is VS Code REST Client's; in the JetBrains HTTP Client, run the login and copy the token into the Authorization header — the file says so in a comment.)

What reads .http files

Why a text file instead of a GUI client?

Honestly, where GUI clients win: environments/secrets management, response history, scripted test assertions, team workspaces. If that's your workflow, Mockbird also exports a Postman collection (/m/<project>/postman.json) and an OpenAPI 3.0 spec from the same live schema — same one-curl idea, different format. We haven't found another hosted mock-API tool that generates .http files from a live schema; if you know one, tell us and we'll link it here.

What's in the generated file

• Full CRUD per resource — list (with pagination params pre-filled), get-one, POST with a type-correct example body, PATCH (merge) with a note that PUT replaces, DELETE.
• Filter cheatsheet comments — every field is an exact-match filter; _gte/_lte/_ne/_like suffixes, ?search=, ?sortBy=&order=, ?select= noted inline where you need them.
• Failure simulation blocks — mock_status and mock_delay examples ready to send (more in the docs: chaos injection, rate-limit simulation, response sequences).
• A GraphQL request — same data, typed schema; GET the /graphql URL in a browser for GraphiQL.
• Auth chain when the project is protected (see above).

Schema only, by design: the file contains no records (your data isn't baked into a shareable artifact) and is public like the other schema exports — openapi.json, postman.json, types.ts — even in protected mode. Limits: 10,000 requests/project/day, 1,000 records/resource. All limits.

More guides: testing loading & error states · Postman mock server alternative · mock server from an OpenAPI spec · mock JWT auth. Create your API →