// mock server
Mock Server
Resonance's built-in mock server listens on a local port and returns responses derived from your OpenAPI collections. No internet connection needed — the entire thing runs on your machine.
What It Does
- Serves mock responses from imported OpenAPI 3.0 collections
- Generates example payloads from schemas when no custom response is defined
- Lets you override the response body, status code, and delay per endpoint
- Logs every incoming request so you can inspect method, path, headers, and body
- Collections can be enabled or disabled individually without restarting
Before You Start
- Import an OpenAPI 3.0 specification — see Getting Started
- Confirm the collection contains the endpoints you want to mock
- Pick a local port that nothing else is using (e.g.
3000)
Starting the Server
- Click the Mock Server action in the toolbar
- Set the port and enable the collections you want to expose
- Review generated routes and their default response settings
- Click Start Server
- Point your client or frontend at
http://localhost:<port>
How Responses Are Generated
- Each defined path and method becomes a mockable route
- Schema examples are generated from the OpenAPI definition where available
- Status codes and content types follow the configured response settings
- Custom overrides take priority over generated defaults
Customising Endpoints
- Select an endpoint in the mock server dialog
- Change the response status code if needed
- Provide a custom JSON body to replace the generated payload
- Add an artificial delay to simulate latency
- Save the configuration — changes take effect immediately without a restart
Testing Against the Mock
Use the mock base URL exactly as you would a real API. Pair it with an environment variable so switching between real and mocked is a one-click operation.
GET http://localhost:3000/users
POST http://localhost:3000/orders
Authorization: Bearer {{token}}
- Set
baseUrl → http://localhost:3000in a Mock environment and switch to it from the selector - Use test scripts to chain extracted values between mock requests
- Artificial delays help verify loading states, retries, and timeout handling in your client
Request Log
Every request that hits the mock server appears in the log — method, path, timestamp, query parameters, and body. Use it to confirm your frontend is calling the right routes with the right payloads.
Typical Workflow
- Import an OpenAPI collection
- Start the mock server on a local port
- Switch your active environment to the mock base URL
- Run your frontend, tests, or external client against the mocked routes
- Refine custom responses and delays until the behaviour matches your scenario
Troubleshooting
Server will not start
- Check whether another process is already using the port
- Try a different port and restart
- Confirm at least one collection is enabled
Route returns an unexpected response
- Verify the OpenAPI operation exists for that method and path
- Check whether a custom override is replacing the generated response
- Review the selected status code in the endpoint configuration
Client cannot connect
- Confirm the client is targeting
localhoston 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
- Getting Started — request basics and environment setup
- Collection Runner — run multi-step flows against mocked endpoints
- Using Scripts — automate flows and validate mock responses