HTTP Mocking Scenarios

Keep handlers in code as the source of truth for API contracts and normal scenarios. Use runtime controls to inspect their requests and responses, then check slow responses, failures, alternative data, and real backend integrations without rewriting the handler.

Explore API states and verify the resulting UI

Select an existing handler in the HTTP panel, confirm the endpoint it represents, then change its response behavior for the scenario you want to test.

1. Loading. Apply delay to keep the request pending and verify skeletons, spinners, disabled inputs, and waiting UX.
2. Failure. Apply network error or a supported error status to verify error copy, retry paths, fallbacks, and how the UI handles existing data.
3. Alternative data. Save a custom response, select custom response in the Behavior column, and return an empty list, long text, an unauthorized user, or unexpected fields. Confirm the API response and verify empty states, layout, permission UI, and defensive data handling.
4. Real backend. Disable the mock at runtime to verify the real API integration without commenting out a handler or restarting the development server.
5. One-off flow. Add a temporary handler for an endpoint or response that is not yet in code. Explore a new UI flow or edge case, then remove it or reset the Dev Tool.

When a handler or the global Mock Enable switch is off, MSW does not intercept that request or WebSocket connection. The request can reach the configured backend, so use a local or staging backend and non-sensitive data when exercising this scenario.

For the complete behavior list, custom-response editor, per-handler mock toggle, and supported status codes, see Handler Table. The custom response behavior is applied in two steps: save the response in the Custom Response column, then select custom response in the Behavior column.

Explore a one-off flow

Use Add Temp Handler to create a temporary HTTP endpoint with a method, path, status, headers, delay, and response body. This lets you create a mock API for an exploratory scenario without adding a handler to application code. Temporary handlers are stored with the active browser session and are removed by Reset Dev Tool.

Use dynamic response templates

HTTP temporary-handler responses and custom responses can interpolate values from the MSW resolver arguments. A template must use the ${{...}} marker, and the prefix must be one of the resolver argument names: request, requestId, params, or cookies.

Use dots to access properties. For example, ${{params.id}}, ${{cookies.locale}}, ${{requestId}}, ${{request.query.page}}, and ${{request.body.user.name}} are valid paths. The same syntax works in the response body and response-header values.

request.body is parsed as JSON for JSON requests and is text for other request content types. If a value is an object or array, it is inserted as JSON. When a value is inserted into a JSON string, quotes, backslashes, and control characters are escaped automatically.

Unsupported prefixes, missing properties, and values that cannot be read leave the original ${{...}} token in the response. The template language does not evaluate JavaScript, call functions, or support custom delimiters. Dynamic templates are currently supported for HTTP only.

Example: configure a response with request data

Response bodies for temporary handlers and custom responses can contain interpolation values:

{
  "id": "${{params.id}}",
  "page": "${{request.query.page}}",
  "name": "${{request.body.name}}",
  "locale": "${{cookies.locale}}",
  "requestBody": ${{request.body}}
}

Response headers can contain interpolation values as well:

{
  "X-Request-ID": "${{requestId}}"
}

For this request:

POST /api/users/42?page=2
Cookie: locale=ko
Content-Type: application/json
 
{"name":"Ada \"Lovelace\""}

The response body is:

{
  "id": "42",
  "page": "2",
  "name": "Ada \"Lovelace\"",
  "locale": "ko",
  "requestBody": {
    "name": "Ada \"Lovelace\""
  }
}

Reset a scenario

Reset Dev Tool restores behaviors to their defaults, enables the global and per-item mock controls, removes temporary HTTP and WebSocket handlers, and closes active mocked WebSocket connections. Use it before moving to another scenario. See Tools for the complete reset and temporary-handler reference.