A rule is an instruction for Mittelware: when traffic looks like this, then do that. Rules are how you go from watching traffic to changing it, whether that means blocking a request, mocking an API or testing how your app handles a server error.

This page has two halves. First, a step-by-step walkthrough where you build one rule with a screenshot of every field. Then a guide to the actions, with a detailed page for each one: what it does, every setting, and how to try it.

If terms like "request", "status code" or "body" are unfamiliar, read Start here first.

The shape of every rule#

Every rule has the same parts, in the same order on screen:

The Rules page#

Open Rules in the sidebar to see your rules.

1. Create Rule starts a new rule.
2. The switch in the Status column turns a rule on or off. An off rule does nothing but stays saved, which is perfect for rules you only need sometimes.
3. The three-dot menu at the end of a row holds more actions for that rule.

Each row shows the rule's name, its action (here Modify Response), the application it watches, and when it was last changed. The application filter and the sort button above the table help when you have many rules.

Build your first rule, step by step#

Goal: whenever Microsoft Edge asks for https://jsonplaceholder.typicode.com/users/1, ignore the server's real answer and return a fake user called Ada Lovelace instead.

This is the same rule as in Getting started. Use any browser you like. Just choose it as the source in step 1.

Before you begin, make sure the browser is opened through Mittelware and monitoring is on.

Step 1: Create the rule and choose the source#

Click Create Rule. An empty form opens. The right-hand panel, About Rules, explains each field as you go.

1. Source
2. Label
3. When…
4. Then…

Click the Source box and start typing the name of your browser, for example Edge. The list shows every program Mittelware found on your computer, so typing is the fastest way to find yours. Click it to select it.

You can pick more than one application. The rule then applies to all of them.

Step 2: Give it a label#

In Label, type a name that tells future-you what the rule does: Docs: fake user. Good labels describe the effect ("Block ads", "Mock users API") rather than the technique.

Step 3: Say when it should run#

Under When… click Add Condition. A menu offers every kind of condition, grouped into three columns:

Choose URL. A row appears with three boxes: what to look at, how to compare, and the value. Open the middle box, Operator:

Pick contains, then type jsonplaceholder.typicode.com/users/1 in the value box.

Step 4: Say what should happen#

Open the Then… box. It lists the actions, each with a one-line description:

Choose Modify Response. This one lets you change what comes back to the app. It starts empty with an Add button, because every part is optional. Click Add to see what you can change:

Choose Body. A code editor appears. Leave Raw selected and paste the fake answer:

{"id": 1, "name": "Ada Lovelace", "email": "ada@example.com"}

The finished form looks like this:

1. Source: only Edge's traffic.
2. Label: the name shown in the Rules list.
3. When: the URL condition.
4. Then: Modify Response.
5. The new body to return.

Leave Delay at 0.

Step 5: Save it#

Click Create in the top-right corner. The rule is saved and active straight away. There's no restart, and it applies to the very next matching request. You land on the rule's edit view, which has an Enabled switch and a Save button for later changes.

Step 6: Try it#

In the browser, open this address (the ?demo=1 matters, see the note below):

https://jsonplaceholder.typicode.com/users/1?demo=1

The server really did send back Leanne Graham, but the browser shows your reply:

Now open Flows to see what happened. The row has a shield icon, and its Details panel carries a badge with your rule's name:

Congratulations, you've written a working rule. When you're done, turn it off with the switch on the Rules page, or delete it. Otherwise it will keep answering for that URL.

Choosing an action#

You've now built one rule. Everything else is the same form with a different When… and a different Then…. Each condition and each action has its own page with the full detail.

Conditions (When…)#

A rule runs on traffic that matches all of its conditions. They can look at the URL, the request (method, headers, query parameters, body) or the response (status code, headers, body), using comparisons such as contains, is, starts with, matches regex and is one of. Conditions lists every category and operator, and explains how request and response conditions change which actions you can pick.

Actions (Then…)#

Not sure which to use? Ask what you want to happen:

• "Make it fail." → Block. A status code, or a timeout.
• "Make it succeed with different data." → Modify Response, or Stream a response if the data should arrive piece by piece.
• "Send it somewhere else." → Modify Request for every call, or Proxy to endpoint only when the real answer is, say, a 404.
• "Let me look at it and decide." → Pause and Review.

The Delay field#

Every rule has an optional Delay (ms). It waits that many milliseconds before the action happens, whatever the action. It's how you make a response slow: see Test timeouts and slow responses.

Row menu: make a copy, delete#

At the right end of each row in the Rules list, the three-dot menu has two actions.

1. Make a copy opens a dialog with the name Copy of … ready to confirm. The copy is created switched off and opened for editing, so a copy of a live rule can never act on traffic before you've changed it. Use it to build a variant, such as the same rule with a different status code.
2. Delete removes the rule for good, after asking you to confirm. To keep it but stop it running, use the switch in the Status column instead.

Order and switching rules off#

Rules are evaluated in the order shown on the Rules page, from the top, so the top row is the one that wins a match first. Use the switch on any rule to disable it without deleting it.

Limits#

• Streaming responses (text/event-stream and similar) are followed live, and you can see them chunk by chunk in the Flows Stream view. Because their body isn't captured whole, a Response Body condition can't match them. Status Code and Response Header conditions still can.
• Bodies over 32 MB aren't captured, so a Response Body condition can't match them either.
• HTTPS rules only work once you've trusted the certificate. See HTTPS & certificates.

Ready-made ideas#

The blog has complete, worked examples:

• Mock an API before it exists
• Simulate a 502 without touching the backend
• Test timeouts and slow responses
• Redirect a production API to localhost
• Rule tricks you'll use every day
• Why developers still need a network interceptor in the AI era