When to use it
Cases shine when you have more than one meaningful way to run a journey:- Happy path — valid credentials, complete data, expected success.
- Missing funding source — a user account with no payment method attached.
- Expired token — a token past its TTL to test 401 handling.
- Edge case input — a particularly large body, a special character in a name field.
Key concepts
A case saves value configuration, not execution results. A case is the input side — the “what values does this run use” snapshot. Results from a run are separate. Cases can be created, renamed, duplicated, archived, and restored. You can maintain a small library of named scenarios without cluttering the active list. Selecting a case autofills values. When you pick a case before running, Reqflo fills in the values the case knows about. You can still override individual values before starting the run. Cases and environments are different things. A case describes the data you’re sending (credentials, IDs, body content). An environment describes the system you’re sending it to (base URLs, service config). You combine them: run the “Expired token” case against thestaging environment, for example.
A pinned or default case may be added in a future release to make it easier to share a recommended starting configuration — but this behavior isn’t finalized, so don’t rely on it yet.
How it works
- Configure a journey run with the values you want to save.
- Save the configuration as a named case (“Happy path”, “Missing funding source”, etc.).
- The next time you run — in the editor, a runbook, or the CLI — select that case by name. Values are pre-filled.
- If the journey’s value requirements change, you may need to update the case.
Examples
A payment journey might have three cases:| Case name | user_id | card_token | Expected outcome |
|---|---|---|---|
| Happy path | usr_001 | tok_valid | Order created |
| Expired card | usr_001 | tok_expired | 402, card declined |
| Missing address | usr_002 | tok_valid | 422, validation error |