← All guides

A fake e-commerce API for prototypes and demos

Every portfolio project, UI-library demo and frontend workshop eventually needs the same thing: a shop backend. Products with prices and images, customers, orders with statuses, reviews with ratings — and crucially, relationships between them, because that's where interesting UI lives.

Public fixtures like JSONPlaceholder or Fake Store API give you fixed, read-only data that everyone else's demo also uses. Mockbird gives you your own store — writable, re-seedable, with real foreign keys — in one click.

1. One click, four linked resources

In the dashboard choose the ecommerce preset next to "New project", or via API:

curl -X POST https://HOST/api/projects \
  -H 'content-type: application/json' \
  -d '{"name":"demo-shop","preset":"ecommerce"}'

You get products, customers, orders (with customerId and productId) and reviews (with productId) — all seeded with plausible data whose foreign keys actually resolve.

2. The queries a shop UI actually needs

# product grid: page 1, cheapest first
GET /m/abc123/products?page=1&limit=12&sortBy=price&order=asc

# search-as-you-type
GET /m/abc123/products?search=chair

# order history for the "logged-in" customer, newest first
GET /m/abc123/orders?customerId=7&sortBy=date&order=desc

# admin view: shipped orders WITH the customer object joined in
GET /m/abc123/orders?status=shipped&_expand=customer

# product detail page: the product plus its reviews, one request
GET /m/abc123/products/4?_embed=reviews

# or path-style:
GET /m/abc123/products/4/reviews

3. Checkout flow, for real

Because the API is writable, your "place order" button can actually place an order:

POST /m/abc123/orders
{"customerId": 7, "productId": 4, "status": "pending"}

# later, in your fake admin panel:
PATCH /m/abc123/orders/31
{"status": "shipped"}

The new order shows up in every subsequent list request — state that persists across page reloads and devices, which is exactly what makes a demo feel real. Re-seed from the dashboard whenever you want a clean slate.

4. Demo-proof the edge cases

GET /m/abc123/products?mock_delay=3000   # skeleton screens on the projector
GET /m/abc123/orders?mock_status=500     # "and here's our error handling"

Handy in workshops: attendees each create their own project (no signup required), so nobody overwrites anyone else's data — a classic failure mode of shared demo APIs.

5. Hand off the contract

Your project publishes a live OpenAPI 3.0 spec at /m/abc123/openapi.json. Import it into Swagger UI or Postman, or generate a typed client — useful when the demo grows into the real thing.