Mock Server

Resonance includes a built-in mock server for testing clients before a backend is ready. It can serve OpenAPI-derived responses locally, let you override payloads per endpoint, and record incoming requests while you iterate.

What It Does

  • Serve mock responses from imported OpenAPI collections
  • Enable or disable collections individually
  • Override generated responses with custom bodies
  • Add per-endpoint delays to simulate slower services
  • Inspect incoming requests in a live request log

Before You Start

  1. Import an OpenAPI 3.0 specification into Resonance
  2. Confirm the imported collection contains the endpoints you want to mock
  3. Decide which local port the mock server should listen on

Starting the Mock Server

  1. Open Resonance and click the Mock Server action in the toolbar
  2. Choose the port to bind, such as 3000
  3. Select the collections you want to expose through the mock server
  4. Review generated routes and response settings
  5. Click Start Server
  6. Point your client or frontend to http://localhost:<port>

How Responses Are Generated

When a route is backed by an imported OpenAPI definition, Resonance uses the available schema information to build mock responses. That makes it useful for early frontend integration and request/response contract validation.

  • Defined paths and methods become mockable routes
  • Schema-backed examples are generated from the specification when possible
  • Status codes and content types follow the configured mock response
  • Custom overrides take precedence over generated defaults

Customizing Endpoints

  1. Select a mocked endpoint from the mock server dialog
  2. Adjust the response status if needed
  3. Provide a custom JSON response body to replace the generated payload
  4. Set an artificial delay to simulate network or backend latency
  5. Save the endpoint configuration before restarting or refreshing the server

Testing Against the Mock Server

Once the server is running, use the mock base URL exactly as you would a real API.

GET http://localhost:3000/users
POST http://localhost:3000/orders
Authorization: Bearer {{token}}
  • Use environments to switch between real and mocked base URLs
  • Pair the mock server with scripts to chain test data between requests
  • Use artificial delays to verify loading and retry states in your client

Request Log and Inspection

The request log helps verify that your application is calling the expected routes with the expected payloads.

  • Inspect incoming methods, URLs, and timestamps
  • Confirm query parameters and request bodies match your expectations
  • Use the log to spot missing headers, incorrect paths, or repeated calls

Typical Workflow

  1. Import an OpenAPI collection
  2. Start the mock server on a local port
  3. Switch your active environment to a mock base URL such as http://localhost:3000
  4. Run your frontend, tests, or external client against the mocked routes
  5. Refine custom responses and delays until the behavior matches your scenario

Troubleshooting

Server will not start
  • Check whether another process is already using the configured port
  • Try a different local port and restart the mock server
  • Confirm at least one collection is enabled for mocking
Route returns an unexpected response
  • Verify the OpenAPI operation exists for the method and path you are calling
  • Check whether a custom override is replacing the generated response
  • Review the selected status code and response body in the endpoint configuration
Client cannot connect
  • Confirm the client is targeting localhost with the correct port
  • Verify the server is still running in Resonance
  • Check that local firewall or container networking is not blocking the port

Next Steps