Export saves rules to a small file. Import adds the rules from such a file to the list. Together they let you:

• Share a rule with a teammate: send them the file instead of a list of steps.
• Keep a backup before you tidy up or reinstall.
• Move your rules to a new computer.
• Keep a library in your project, such as a mittelware-rules.json in the repository, so anyone who joins can import the rules the team uses.

Both buttons are at the top of the Rules page.

Export#

There are four ways to export, and they differ only in which rules go into the file:

Click the button and a Save dialog asks where to put the file. When it's written, a message says what was exported: Exported 2 rules, or Exported "Fail checkout (502)" for a single rule. If you cancel the dialog, nothing is written. With no rules in the list, the message is There are no rules to export.

What is in the file#

The file is a JSON object with a rules list: one entry per rule, even when there is only one. The rules are in the order Mittelware tries them, which is the order of All rules (collection by collection, top first). This is what exporting Fail checkout (502) writes:

{
  "rules": [
    {
      "label": "Fail checkout (502)",
      "sources": ["Microsoft Edge"],
      "enabled": false,
      "action": "block_response",
      "conditions": [
        {
          "category": "url",
          "field": "fullUrl",
          "id": "6581deca",
          "operator": "contains",
          "value": "jsonplaceholder.typicode.com/todos/1"
        },
        {
          "category": "method",
          "field": "method",
          "id": "64819a0b",
          "operator": "is",
          "value": "GET"
        }
      ],
      "action_details": {
        "block_response": {
          "code": "502"
        }
      },
      "delay_ms": null,
      "collection": "Checkout flow"
    }
  ]
}

What the file leaves out is what belongs to your copy of Mittelware: the rule's internal id, its position in the list and its dates. An imported rule gets new ones. The file doesn't carry your variables either: a rule that reads {{vars.token}} holds only that tag, never the token's value. Older files that are a bare list of rules, [ ... ], still import.

Import#

Click Import at the top of the Rules page and choose a .json file, for example one that Export wrote. Mittelware reads it, adds the rules, and shows a message such as this one:

Importing adds rules. It never replaces or changes the ones you already have:

• Each rule is new. Importing the same file twice gives you two copies of every rule.
• They go into the collection the file names. A rule goes into the collection with that name, matched without regard to capital letters, and Uncategorized is the default one. A collection you don't have is made for you, and the message says how many were made. A file with no collection names (an older file) imports into the collection you have open, or into Uncategorized when you are looking at All rules.
• They go to the top of their collection, in the order they are in the file. Rules are checked from the top, so imported rules take priority over the ones you had in that collection. See Order, and when two rules act on one request.
• On or off stays as it was in the file. A rule exported while switched on starts acting the moment it is imported.
• A name already in use is changed. Every rule needs its own name, so a rule called Mock todo is added as Mock todo (imported) when you already have one, then Mock todo (imported 2), and so on. The message tells you how many were renamed.

When a file can't be imported#

If the file as a whole isn't usable, nothing is imported and the message says why:

If only some rules are the problem, the rest are still imported, and a warning lists what was skipped and why (up to three, with a count of the others):

A rule is skipped for the same reasons the form wouldn't let you save it: a pattern that isn't a valid regular expression, no application, or more than five applications. Fix the rule in the file and import again. The rules that did import would be added a second time, so leave them out of the file, or delete the copies afterwards.

After importing: what to check#

Rules from another computer or another person are only as good as what they refer to. Open each imported rule and check:

1. The application. A rule names its applications, such as Microsoft Edge. On a computer without that app, or where it has a different name, the rule imports fine and then never matches. Open it and pick the right App.
2. Files. A body or payload that comes From file remembers the path on the computer it was exported from. If that file isn't there, it can't be read when the rule runs. Open the rule and choose the file again.
3. Variables. A rule that reads {{vars.name}} finds nothing until you add that variable on the Variables page.
4. Values that belong to someone else. Addresses, hosts, ports and tokens in the rule may point at another person's setup, such as a localhost:3000 server you don't run.

Editing the file by hand#

The file is ordinary JSON, so you can open it in any editor to rename a rule, change an enabled flag, or copy a rule's entry to make a similar one. Hand-written rules go through the same checks as imported ones: the easy way to learn the shape of an entry is to export a rule you made in the form and look at it.

Related#

• Rules overview
• Collections
• Variables
• Order, and when two rules act on one request
• Seven rule tricks you'll use every day: keep a library of rules