E-commerce API with Mock API Studio
The editor below is preset with a four-resource store: customers, orders that point at a customer, products, and reviews that point at a product and a customer. Free keeps 2 resources, so on Free you create customers and orders and can build order history, a checkout that POSTs an order, and an admin screen that moves orders from paid to shipped; the full four-resource store is Pro.
- Check the four resources. On Free, untick two of them (customers and orders are the free pair this guide uses); keeping all four needs Pro. The five sample orders define the order statuses (pending, paid, shipped, delivered, cancelled), so generated orders only use those and anything else is rejected.
- Keep 25 records per resource (the free maximum) and press Create my API. customerId is filled with customer ids that exist, and so is reviews.productId when products and reviews are included on Pro.
- Build order history: GET /orders?customerId=1&sort=createdAt&order=desc, and a status filter with ?status=shipped&status=delivered.
- Build checkout: POST /orders with {"customerId":1,"status":"pending","items":[{"productId":1,"qty":1,"price":38}],"total":38,"currency":"USD"} returns 201 and a Location header.
- Build fulfilment: PATCH /orders/3 with {"status":"shipped"}; a status that is not in the list returns 422. On Pro, show reviews with GET /reviews?productId=1.
What to know
A shop frontend is several apps sharing one dataset: a storefront that reads products, an account area that reads one customer's orders, a checkout that writes an order and an admin that changes order status. Mocking each screen with its own fixture file means the order you create in checkout never shows up in the account area. One stateful API removes that gap, because every screen reads and writes the same stored records.
Order status is the field most worth testing, and it is validated: the list is exactly the statuses in your sample orders, so PATCH {"status":"refunded"} returns 422 until you add a refunded sample. That lets you test the error branch of a status dropdown. The items array is copied from your sample orders, so generated orders carry realistic line items; total is a generated price, so do not expect it to equal the sum of the items unless you set it yourself in a POST.
Queries cover the usual admin views without a backend: ?status=pending is the to-ship queue, ?total_gte=100 finds large orders, ?createdAt_gte=2026-10-01 is this month, /customers?q=austin finds a customer by any text field, and _page with _limit pages the table with X-Total-Count for the footer. On Pro, reviews filter the same way: /reviews?productId=1&rating_gte=4.
This API stores data; it does not process payments, compute tax or decrement stock when an order is placed. Your frontend makes those calls itself, for example a PATCH to /products/1 (on Pro, where products sits next to orders) with the new stock after a POST to /orders. That keeps the mock predictable and makes your client code do the same sequence of requests it will do against the real backend.
Updated · Cosmovex
Questions
Does placing an order reduce product stock?
No. Each resource is independent CRUD, so the API never changes one resource because another changed. Send a PATCH /products/:id with the new stock from your checkout code if your UI needs it, the same way a client would call two services.
How do I list one customer's orders?
GET /orders?customerId=1, optionally with &sort=createdAt&order=desc and &_page=1&_limit=10. With Pro you can also call /customers/1/orders, and ?_expand=customer embeds the customer object in each order.
Can I add more order statuses?
Yes. Add a sample order with the new status (for example refunded) before pressing Create my API; the allowed list is the set of statuses in your samples. After creation you can edit the field's values in the field table.
Can I keep all four resources on the free plan?
No. Free keeps 2 resources per project and 25 records each, which covers customers and orders for order history, checkout and fulfilment. Products and reviews as well need Pro, which allows 50 resources and 5,000 records per resource for carts, coupons, addresses and so on. On Free, the Pro wall offers to create the first two ticked resources instead.
Can I test what happens when checkout fails?
On the free plan, invalid bodies return 422 and unknown ids 404, which covers form errors. Pro adds error injection (a chosen rate of 500, 502 or 503 responses), route rules that force a status on POST /orders, and added latency for spinner states.
The free plan covers everything on this page. Mock API Studio Pro ($5/mo, billed monthly) is described on the Mock API Studio page.
