Rules — Conditional Responses
The Rules sub-tab on a non-default response variant is where you describe when that variant should be returned. Rules only matter for non-default variants; the default variant is the fallback and its Rules tab is informational only.
Two States of the Rules Tab
The contents of the Rules sub-tab depend on whether the currently active variant is the default or not:
- •On the default variant: the tab shows a single info box that reads "This is the default response. It is returned when no other response's rules match. Rules are not evaluated for the default response." There is nothing to edit.
- •On a non-default variant: the tab shows a short reminder — "This response is returned when the incoming request matches the rules below. Groups are combined with OR — any matching group selects this response." — and the rule builder itself.
Rule Groups
Rules are organised in groups. A group is a small card that holds one or more individual rules. Groups are themselves combined with OR: if any group matches, the variant wins. Within a group, the rules can be combined with either AND or OR, and that choice is per group — one group can be "match ALL of these" while the next one is "match ANY of these".
- •Group header: reads "Match ALL of these conditions" or "Match ANY of these conditions". Clicking the word ALL or ANY toggles the group between AND and OR.
- •Separator between groups: a thin line with the word OR in the middle, to make it visually obvious that groups are OR-combined regardless of their internal operator.
- •Remove group: a small X in the top-right corner of the group card. Visible only when there is more than one group — the last remaining group cannot be removed this way.
- •Add group: the Add Rule Group button under the list creates a new empty group with one starter rule inside it.
- •Add rule inside a group: the small Add Condition link at the bottom of each group adds another rule to that same group.
A Single Rule
Each row inside a group is a single rule. A rule has an enable checkbox on the left (disabled rules are dimmed and ignored at match time), and then three or four configuration fields depending on the target:
- •Target: a dropdown with three choices — Body, JSON Path, or Header. Changing the target resets the rest of the row so a half-finished rule cannot be left in an inconsistent state.
- •Property: a text field that means different things for different targets. For Header it is the header key (e.g. X-Tenant-Id). For JSON Path it is a JSON path expression starting with $.. For Body the property field is hidden, because the whole body is the target.
- •Operator: a dropdown with equals, not equals, contains, not contains, exists, not exists, is empty, is not empty, and matches regex.
- •Value: the text the operator compares against. Hidden for the four operators that do not need a value — exists, not exists, is empty, and is not empty.
- •Delete: a small trash icon on the right. Deleting the last rule in a group automatically removes the empty group as well.
Empty State
A non-default variant that has no rules yet shows a centred empty state with the text "No rules defined", a short hint ("Add rules to conditionally return this response"), and a single Add Rule Group button. Until at least one group exists, the variant can never be matched — so the default variant is the only one that would ever answer the endpoint.
A Small End-to-End Example
Imagine an endpoint POST /loginwith two response variants. The first variant is the default — a successful login payload. The second variant is an error payload for bad credentials, and its Rules tab contains one group with one rule: target JSON Path, property $.password, operator equals, value wrong. Any request whose body has "password": "wrong" hits the error variant; everything else falls through to the default and succeeds.