Change traffic
Write a URL pattern that matches
On this page
A rule's URL field holds a pattern for the path and query of a request. Test it before you save: a pattern that never matches gives no error while capture runs.
What the pattern is matched against
- Write the path and query only:
/users?*, notapi.example.com/users?*. The host comes from the rule's host filter. - ReqRes puts the scheme and host in front of your pattern and in front of the request's path and query, then compares them. For a rule on
api.example.com,/users?*is compared ashttps://api.example.com/users?*. - The path and the query are compared, over HTTPS and plain
http://alike. - In Wildcard mode, the sheet adds a leading
/if you leave it out. In Regex mode, it saves the pattern exactly as you typed it.
Match with a wildcard
Set Match to Wildcard. The Test the Pattern popover says: "* matches any run of characters, including none. Everything else matches literally, and the pattern must cover the query too — end it with * to match /search?q=…"
- The pattern must match the whole path and query.
/usersmatches/usersbut not/users?id=1or/users/42. Add*where more may follow. - Before ReqRes 1.1, plain
http://ignored the query, so a rule like/searchmatched/search?q=widgetsthere. It now needs the*: write/search*. ?and.are ordinary characters in a wildcard.
| Pattern | Matches |
|---|---|
/api/* | Everything under /api/ |
/items?* | Any query on /items |
/* | All requests to the rule's host |
Match with a regular expression
Set Match to Regex.
- ReqRes searches for your pattern in the whole URL: the scheme, the host, then the path and query.
- Start the pattern with
/. ReqRes joins it straight onto the host. - Do not start it with
^. The host always comes before your pattern, so^can never match there. - End it with
$to match up to the end of the URL. Without$,/users/\d+also matches/users/42/orders. - Escape
?and.with a backslash:\?and\..
| Pattern | Matches |
|---|---|
/api/.*$ | Everything under /api/ |
/items\?.*$ | Any query on /items |
/users/\d+$ | A numeric user id, such as /users/42 |
The sheet checks a regex as you type. While one of these messages shows below the fields, Create stays disabled:
- "Not a valid regular expression."
- "Remove the ^: ReqRes puts the host in front of your pattern, so an anchored one never matches." The message goes on to suggest the pattern without the
^. - "Start the pattern at the path, with /: ReqRes appends it directly after the host."
Test a pattern before you save
- In the rule sheet, click ? beside the URL field. The Test the Pattern popover opens.
- Under ReqRes matches, check the full pattern: the scheme, the host and your path.
- In Try a URL, type or paste a full URL, such as
https://api.example.com/users?id=1. - Read the result: "Matches" or "Does not match".
The popover tests the pattern as the sheet will save it. It takes the host from the URL you type, not from the rule, so paste a URL on the rule's host. Below the result it lists the rules and examples for the current Match setting. With the URL field empty, it reads "Type a pattern in the URL field first."
An agent can run the same check with the test_pattern MCP tool, which creates nothing. See MCP tools.
Avoid the 4 patterns that never fire
The examples are checked against the URLs in the last column.
| Mistake | Never fires | Works | Tested against |
|---|---|---|---|
A regex that starts with ^ | ^/users/\d+$ | /users/\d+$ | https://api.example.com/users/42 |
A regex without a leading / | users/\d+$ | /users/\d+$ | https://api.example.com/users/42 |
| The host typed into the path | /api.example.com/users?* | /users?* | https://api.example.com/users?id=1 |
| A wildcard path that stops before the query | /search | /search* | http://api.example.com/search?q=widgets |
The sheet catches the first 2 and will not save them. The other 2 save with no warning, so test them in Test the Pattern.