Managing Simulated Responses
A saved response defines what a simulated server returns when a matching request arrives. Each URL handler has one default response and any number of named responses selected by conditions.
What it does
The Edit Response window lets you manage every response for a single URL handler in one place. Responses are shown as tabs: the Default tab (always present, cannot be renamed or deleted) plus one tab per named response. For each response you configure the status/type, an optional delay, a condition (named responses only), the body and the reply's headers.
When to use
- You want to return different bodies or status codes for the same endpoint (success vs. error).
- You need an error or edge-case response selected only when a request meets certain conditions.
- You are simulating a typed service (OpenAPI/GraphQL/SOAP) and want to pick a predefined response definition.
How to use
Open the Edit Response window
In the Service Simulation view, select a server and open the Operations tab. For any handler row, use one of:
- The floating toolbar that appears on hover/selection: Manage Responses.
- The ⋮ actions button (or right-click) → Manage Responses.
The Manage Responses command opens the Edit Response window in management mode, with a tab for every response of that handler.
Add a response
Click Add Response in the tab area, type a name in the prompt, and a new named tab is created.
Remove a response
On a named response tab, click its close button (). The Default response cannot be removed — a notification explains this. You are asked to confirm the deletion.
Reorder responses
Use Move Up / Move Down. The Default tab always stays first; named responses are evaluated top-to-bottom, so place more specific responses above more general ones.
Configure the response
For an HTTP/REST handler the left pane starts with a RESPONSE TEMPLATE row — a ComboBox of predefined response definitions from the service metadata, each showing its HTTP status and description (e.g. 200 OK, 404 NotFound; HTTP REST also offers a Custom entry). Selecting one sets the status code and the body editor.
The reply's Delay (fixed wait before responding, in seconds, 0–300 with one decimal) is the first row of the FAULT INJECTION section — see Fault Injection.
For a SOAP handler a strip above the editor shows the SOAP fault controls instead (see below); the delay is in the fault section just the same.
The default response
Each URL handler has one default response (the Default tab, with ResponseName empty). It is returned when:
- No named response's condition matches the incoming request, or
- No conditions are configured.
The default response is always present, cannot be renamed or deleted, and has no condition builder (it shows: "This is default response. It will be selected if no other matching conditions.").
Condition builder
For each named response, the left pane shows the CONDITION builder (see Response Conditions) below the template row. The default response has no condition. Below it — after a draggable divider — sits the FAULT INJECTION section (see Fault Injection); its header badge shows how many fault mechanisms are active. Use Hide Details / Show Details to collapse the pane, and Test Conditions to open the condition tester.
Response headers (BODY / HEADERS tabs)
The response area is a tab strip:
| Tab | Contents |
|---|---|
| RESPONSE | The complete response editor (object tree / wire-format editor depending on the response template — status, headers and body). With the Custom template the reply is a raw HTTP message and the status code is a free dropdown — use it to answer with a status the spec does not declare (e.g. a 200 for an operation that only declares 405). Declared templates pin the status to their code; switch to Custom to answer with anything else. |
| HEADERS | Non-standard headers the reply carries. Add appends a row, Remove deletes the selected one, Clear empties the list; the tab badge shows the header count. |
Headers configured here are stored with the saved response (RequestOptions) and are merged into every served reply, on top of the body's own headers — they travel with the project and with .mockconfig.json exports. They apply to HTTP/SOAP replies (gRPC replies use trailers, which this tab does not edit).
Response body editors
- Object Editor — for typed JSON/XML responses; navigate the response structure in a tree and edit values. Used for standard, metadata-defined responses.
- HTTP Message Editor — full control over the raw HTTP response (status line, headers, body). Used for Custom HTTP responses and for
EmptyResponsetypes.
When you switch the Response Template selector, Aethrix Studio tries to preserve your data by deserializing the existing value into the new type before creating a fresh instance.
SOAP fault simulation
For SOAP handlers, enable Return SOAP Fault (checkbox labeled Activate) to return a SOAP fault. Configure:
| Field | Description |
|---|---|
| Fault Code: | A SoapFaultCode value (e.g. soap:Server, soap:Client, soap:MustUnderstand, soap:VersionMismatch). |
| Fault Message: | The faultstring. |
| Fault Actor: | Optional actor URI. |
| Detail Type: | The fault detail element type. Choose a type from the service's SoapFaultTypes, or leave it empty (EmptyFaultDetail). |
A SOAP fault always returns HTTP 500. When the fault is off, a normal SOAP response returns HTTP 200. See SOAP Fault Simulation.
Save
Click Save Changes to persist all responses for the handler (or Cancel to discard). Changes are written to the active response store (workspace or the current automation test step).
Grid actions
From the Operations grid you can also:
| Action | Description |
|---|---|
| Manage Responses | Open the Edit Response window for this URL handler. |
| Copy Listening URL | Copy the simulated endpoint URL(s) to the clipboard (a flyout lists each bound interface when multiple exist). |
| Clear All Responses | Remove every configured response for the handler (with confirmation). |
Requests counter
The Requests column in the Operations grid shows how many times each handler has been matched. The Responses column shows how many responses are configured (and which is the default). Request counts reset when the server is restarted.
:::info Screenshot needed — light/dark 📸
edit-response-window-light.png and edit-response-window-dark.png — the Edit Response window showing the response tabs, Response Template selector, delay, condition builder, and body editor.
:::
Streaming responses (advanced)
For WebSocket push responses, a saved response can carry a list of streaming frames (StreamingFrames), each with a JSON body Value, a per-frame Delay, and an optional Frame Name shown in the trace. For gRPC server-streaming, the handler's streaming response values/delays are used instead. (Editing streaming frames is not exposed in the Edit Response window UI in the current build — they are defined in the response data model.)