A mock server is a hosted or local HTTP server that returns pre-configured responses instead of running real business logic. Requex gives you a persistent HTTPS mock server where you can define paths, methods, status codes, headers, response bodies, delays, and auth so you can create a mock API quickly and test against realistic endpoints.

TL;DR

•A mock server lets you return fixed or rule-based HTTP responses without building a real backend.
•Use a mock API server to unblock frontend work, integration tests, demos, and failure-state testing.
•Requex mock servers support custom paths, per-method responses, headers, delays, and server-wide auth.
•A hosted HTTP mock server is useful when teammates, CI, Postman, or external systems need a stable public URL.
•The main mistakes are returning unrealistic payloads, ignoring auth, and only testing happy-path `200` responses.

Detailed Explanation

A mock server is a programmable HTTP server that returns pre-configured responses instead of executing real business logic. Instead of spinning up a full backend, you declare what each endpoint should return and let the mock handle requests. That is why developers use mock API servers early in a project: the frontend can keep moving even if the real API is still being designed.

Requex Mock Servers are hosted for you — no local process to keep running, no port-forwarding, no Docker containers. Every mock server gets a stable HTTPS URL that works from any machine, CI pipeline, or Postman collection. That matters when the consumer of the API is not just your laptop, but a teammate, test runner, or third-party integration.

The practical difference between a simple mock response and a useful HTTP mock server is control. A useful mock lets you define paths, request methods, status codes, response headers, body shape, delays, and auth rules. That makes it possible to test success flows, validation errors, rate limits, and timeout behavior before the real backend exists.

Your mock server URL structure

https://api.requex.me/mock/<server-id>/<your-path>

# Examples:
GET  https://api.requex.me/mock/abc123/users
POST https://api.requex.me/mock/abc123/orders
GET  https://api.requex.me/mock/abc123/products/42

Features

🛣️

URL Path Routing

Define any number of paths per mock server. Paths support Express-style parameters — a path like /orders/:id matches /orders/42, /orders/abc, and any other value. Multiple segments work too: /users/:userId/posts/:postId.

✓ /users/:id → matches /users/123

✓ /products/:cat/:id → matches /products/shirts/42

✗ /orders/99 → no match if only /orders/:id is defined

⚡

Per-Method Responses

Each path can have one response per HTTP method: GET, POST, PUT, PATCH, DELETE, or ANY. The ANY method is a wildcard — it matches all methods that don't have a specific response configured.

GETPOSTPUTPATCHDELETEANY

📦

Custom Response Body, Status & Headers

For each method response, configure:

›Status code — any valid HTTP status (200, 201, 204, 400, 401, 403, 404, 422, 500…). Quick-select chips for the most common ones.
›Response body — any text content. JSON, XML, plain text, or empty. The body is returned as-is.
›Custom headers — add any response headers as key-value pairs (e.g. Content-Type: application/json).

⏱️

Response Delay

Set an artificial delay (in milliseconds) on any response to simulate real-world latency or slow upstream APIs. Use this to test loading states, timeout handling, and retry logic in your client code. Set to 0 for instant responses (default). Maximum: 30,000 ms (30 seconds).

🔐

Server-Level Authentication

Protect your entire mock server behind an auth layer. Auth is enforced on every incoming request before route matching. Supports all the same methods as Requex webhooks:

›Bearer Token — validates the Authorization: Bearer <token> header.
›API Key — checks a named header or query parameter against a secret value.
›Basic Auth — decodes and validates Authorization: Basic <base64>.
›HMAC Signature — computes an HMAC over the raw request body and compares to the signature header.
›Custom — read any header, query param, or JSON body path and compare to an expected value.

All comparisons use timingSafeEqual to prevent timing attacks. Configure failure status code (401 or 403) and optional WWW-Authenticate challenge header.

How to Create a Mock Server

Sign in and open Mock Servers

Mock Servers require a free account. Sign in at requex.me, then click Mock Servers in the header nav or user menu.

Create a new mock server

Click New Mock Server. You'll be taken directly to the editor. Your server gets a stable base URL immediately:

https://api.requex.me/mock/<your-server-id>

Add routes

In the left panel, click + Add and enter a path. Use :param for URL parameters:

/users

/users/:id

/orders/:orderId/items

/health

Add responses per method

Select a route, then click + Add Response. Choose the HTTP method and configure the response:

Method:      GET
Status:      200
Body:        {"id": 42, "name": "Alice", "role": "admin"}
Headers:     Content-Type: application/json
Delay:       0 ms

Hit your mock from anywhere

No restart required — changes are live instantly. Test with curl:

# GET a user
curl https://api.requex.me/mock/<id>/users/42

# POST an order
curl -X POST https://api.requex.me/mock/<id>/orders \
  -H "Content-Type: application/json" \
  -d '{"item": "widget", "qty": 3}'

# With Bearer auth enabled
curl https://api.requex.me/mock/<id>/users \
  -H "Authorization: Bearer my-secret-token"

Common Problems / Mistakes

Mocking only the happy path

A `200 OK` response is not enough. If your app never sees `401`, `404`, `422`, `429`, or `500`, you are not really testing client behavior.

Using unrealistic payloads

Hand-written sample JSON often drifts away from the real contract. Keep your mock payloads close to what the real API will return.

Ignoring auth in the mock

If production requires Bearer tokens, API keys, or HMAC signatures, your mock should enforce that too. Otherwise auth bugs stay hidden until late.

Forgetting delays and timeouts

A response that is always instant will not surface loading-state bugs, race conditions, or client timeout handling.

Creating one giant catch-all endpoint

It is usually better to model specific routes and methods so tests behave like the real API, not a loose placeholder.

Common Use Cases

🖥️

Frontend development without a backend

Build and test UI components against realistic API responses before the backend exists. No waiting on the backend team.

🧪

Integration & contract testing

Run automated tests against a stable mock that behaves exactly like the real API. Pin your tests to a specific response contract.

💥

Simulating error states

Return 500, 429, or 503 on demand to test how your app handles upstream failures. Use delay to simulate timeouts.

🔒

Testing auth flows

Enable auth on the mock server and validate that your client sends the correct credentials — Bearer token, API key, HMAC, or Basic.

🎭

Demoing a product

Point a demo app at a mock server that returns beautiful, curated data. No flaky dev database required.

⚡

Third-party API simulation

Recreate Stripe, Shopify, or GitHub API shapes locally for testing without rate limits or test-mode restrictions.

Request Matching Rules

When a request arrives at your mock server, matching happens in this order:

1
Auth check — If auth is enabled on the server, credentials are validated first. Failed auth returns 401/403 immediately — no route matching occurs.
2
Path matching — The incoming path is tested against all defined routes using Express-style pattern matching. The first matching route wins.
3
Method matching — The route's responses are checked for an exact method match (GET, POST, etc.). If none found, a response with method ANY is used as fallback.
4
Condition evaluation — If the matched response has conditional rules, they are evaluated against the live request. If conditions fail, the server falls back to the ANY response. If no ANY response exists, a 404 is returned.
5
No match → 404 — If no route matches the path, or no response matches the method, the server returns a structured 404 JSON error.

Debugging / Practical Tips

Start with one route and one method, then expand. A small, correct mock is usually more valuable than a large mock with guessed behavior.

Keep one example response for success and one for failure on every important route. That gives frontend and QA teams realistic states to test against.

Set `Content-Type` explicitly. Many client bugs come from a mismatch between the body content and the response header.

Use delay intentionally. Add a 2 to 5 second response delay to check spinners, retries, abort handling, and optimistic UI rollbacks.

If the real API uses path params like `/users/:id`, model them that way in the mock instead of flattening everything into query strings.

Conditional Responses

Each response can optionally have condition rules that gate when it fires. Rules inspect the live request — query params, headers, path params, or JSON body fields — and are evaluated as AND or OR logic. When conditions fail, the server falls back to the ANY method response for that route.

Available operators

Operator	Meaning	Value required?
`eq`	Exact match (case-sensitive)	Yes
`neq`	Does not equal	Yes
`contains`	String contains substring	Yes
`startsWith`	String starts with prefix	Yes
`endsWith`	String ends with suffix	Yes
`regex`	Matches a regular expression	Yes
`gt`	Numeric greater-than	Yes
`lt`	Numeric less-than	Yes
`exists`	Field is present and non-empty	No
`notExists`	Field is absent or empty	No

Inspectable sources

Query param

Reads from the URL query string. Key: the param name (e.g. version). Example: ?version=v2

Header

Reads a request header. Key: header name (case-insensitive). Example: x-api-key

Path param

Reads a named segment from the route path. Key: the param name defined in the path pattern (e.g. :id → key "id").

Body field

Reads a JSON body field. Key: dot-notation path. Example: user.role reads body.user.role.

Example: version-based routing

Route /api/data with two responses:

GET response — conditions: query.version eq "v2"

# Fires only when ?version=v2 is in the URL
curl https://api.requex.me/mock/<id>/api/data?version=v2
→ 200  {"version":"v2","data":[...]}

ANY response — no conditions (fallback)

# Fires for any other request (missing or wrong version)
curl https://api.requex.me/mock/<id>/api/data
→ 400  {"error":"version parameter required"}

How to add conditions to a response

Open a mock server and select a route.
Click Add Response or Edit on an existing one.
Switch to the Conditions tab inside the modal.
Add one or more rules. Choose source, key, operator, and value.
Set match mode: ALL (every rule must pass) or ANY (at least one must pass).
Save. A purple Conditional badge appears on the response card. Hover it for a tooltip showing the rule logic.

Tools to Use

Requex (https://requex.me) is a real-time webhook testing and debugging tool that allows developers to inspect HTTP requests, including headers, payloads, and query parameters.

For hosted API mocking, Requex is useful when you need a stable HTTPS endpoint with programmable responses, delays, and auth. If you want a desktop-first local workflow, tools like Mockoon can also be useful. If you prefer contract-first mocking, Prism or Postman mock servers may fit better depending on your stack.

The best choice depends on whether you need a public URL, local-only development, OpenAPI-driven mocks, or request inspection alongside response mocking.

FAQ

What is a mock server used for?

A mock server is used to simulate an API before the real backend is ready, or to reproduce specific responses like errors, delays, and fixed payloads during testing.

What is the difference between a mock server and a fake API?

In practice, developers often use the terms interchangeably. A mock server usually emphasizes programmable HTTP behavior, while a fake API can refer more broadly to any simulated backend.

Can I create a mock API without writing backend code?

Yes. Hosted tools let you define routes, methods, status codes, headers, and response bodies from a UI, so you do not need to deploy your own Express, Fastify, or Flask server.

Should a mock server return real-looking data?

Yes. The closer your mock payloads are to the real contract, the more useful your tests and frontend work will be. Unrealistic payloads often hide integration bugs.

Can a mock server require authentication?

It should if the real API does. Requex mock servers support auth modes like Bearer token, API key, Basic Auth, HMAC, and custom validation so your test environment stays realistic.

When should I use a hosted HTTP mock server instead of a local one?

Use a hosted mock when teammates, CI jobs, Postman collections, or external systems need to reach the endpoint over the internet. Local mocks are fine when everything stays on one machine.

Current Limits

·Mock servers require a free Requex.me account (sign up in under 10 seconds).
·One response per HTTP method per route (you cannot define two GET responses for the same path).
·Maximum response delay: 30,000 ms (30 seconds).
·Auth is server-wide — you cannot set different auth per route or per method.

Ready to build your mock?

Open Mock Servers →Quickstart Guide

Related Resources

Quickstart GuideGet your first webhook URL in 60 seconds.Webhook Security Best PracticesBearer tokens, HMAC, and API key auth explained.Complete Webhook Testing GuideEnd-to-end webhook testing workflow.Requex vs Webhook.siteFeature comparison including custom responses.