Workflow Syntax Reference
A Transition is a rule that defines how Mockzilla should react to a request when operating in Workflow Mode. By combining Conditions and Effects, you can build incredibly complex, stateful API prototypes without writing a single line of backend code.
State
Simple key-value store for session data like tokens or flags.
Mini-DB
Collection-based storage for tables of users, orders, or logs.
Input
Direct access to request body, headers, query, and path params.
1. Conditions
Conditions determine whether a transition is triggered. Mockzilla's condition engine is highly resilient and gracefully handles messy real-world data.
| Property | Description |
|---|---|
| Selector | A JSON path to the value you want to check (e.g., input.body.id, state.token). |
| Operator | eq (==), neq (!=), gt (>), lt (<), exists, contains. |
| Value | The value to compare against. Supports full interpolation with {"{{ }}"}. |
If you use a selector like id without a prefix, Mockzilla will automatically try to find it in input.body.id or input.params.id.
Advanced Condition Edge Cases
- Robust
contains: Works seamlessly across arrays and strings. Ifstate.tagsis["admin", "beta"], a condition checking if itcontains"beta"will pass. It safely returnsfalseif the target isnullorundefined. - Safe Type Coercion (
gt/lt): Mockzilla safely coerces string-numbers (like"42") into actual numbers. If the value isn't a number (like"apple"), it safely evaluates tofalsewithout crashing. - Graceful Missing Paths: If you use the
existsoperator on a deeply nested path that doesn't exist (e.g.,state.missing.user.id), Mockzilla safely returnsfalserather than throwing an error.
2. Effects
Effects are actions that modify the Scenario State or the Mini-DB when a transition fires. You can stack multiple effects in a single transition.
| Effect | Description |
|---|---|
state.set | Sets a key in the session state to a specific value. |
db.push | Appends a new record to an array (table) in the Mini-DB. |
db.update | Modifies existing records in a Mini-DB table that match your criteria. |
db.remove | Deletes records from a Mini-DB table that match your criteria. |
Complex Effect Scenarios: Best Ways to Use
- Multi-Step State Updates: Effects run in order. If your first effect sets
state.countto10, your second effect can immediately use{"{{state.count + 5}}"}to set another variable to15. - Bulk Database Updates: The
db.updateeffect is powerful. If you specify a match criteria (e.g.,role == "admin"), Mockzilla will update all matching rows in the table simultaneously, not just the first one. - Auto-Initialization: If you use
db.pushon a table that doesn't exist, Mockzilla automatically creates it for you on the fly.
3. The Mini-DB (db)
The Mini-DB is a persistent JSON store. Each Scenario has its own isolated database.
Accessing Database Values
You can access your data using standard dot notation or advanced array predicates:
- Relational Lookup (Literal):
{"{{db.users[role=admin].name}}"}(Finds the first user where role is "admin") - Relational Lookup (Dynamic):
{"{{db.users[id=input.params.id].email}}"}(Finds the user whose ID matches the current URL parameter)
4. Execution Rules & Best Practices
To master Workflow Mode, follow these core patterns:
Mockzilla checks your transitions from top to bottom. The first transition whose path, method, and conditions match is the only one that fires.
Always put transitions with specific conditions (e.g., password == "wrong") at the top. Put a duplicate transition with the same path but no conditions at the bottom to act as a default success or error fallback.
Use a transition with no conditions as the final entry for a specific path to return a 401 Unauthorized or 404 if none of your specific logic was triggered.