Rules

Rules in RequestRocket control whether each request is allowed or denied. They provide fine-grained access control by evaluating each request against path, HTTP method, headers, and query parameters using regular expressions. Rules can be configured at Credential, Proxy, and Target levels.

How rules work

Evaluation order

Rules are checked at three levels. A request must pass all levels to be allowed; any Deny at any level blocks the request.

1. Credential rules — Apply to all proxies (or targets) that use that credential.
2. Proxy rules — Apply only to requests through that proxy.
3. Target rules — Apply to all requests destined for that target.

Within each level, rules are sorted by priority (higher number = evaluated first). The first rule that matches the request determines the outcome for that level.

Default behavior

Each proxy (and credential/target) has a default effect: Allow or Deny. When no rule matches the request, this default is used.

• Default Allow — Unmatched requests are allowed (use Deny rules to block specific cases).
• Default Deny — Unmatched requests are denied (use Allow rules to permit specific cases).

What a rule can match

Each rule can optionally restrict by:

If you leave methods, path, headers, or query checks empty, that part of the rule does not filter (e.g. “all paths” or “all methods”).

Matching criteria

A rule matches a request when all of the following are true (when specified):

• The request’s HTTP method matches (if methods are specified)
• The request’s path matches the path pattern (if specified)
• All header checks pass (if specified)
• All query parameter checks pass (if specified)

Where rules can be applied

Credential rules apply to all proxies that use that credential. Use them for organization-wide policies, blocking specific methods or paths across services, or enforcing header/query requirements.

Proxy rules apply only to a single proxy. Use them for proxy-specific access, testing rules before rolling them out, or different policies per integration.

Target rules apply to all requests destined for that target, adding another layer of control at the target level.

Regex examples that work

Rules use Regular expressions. The path (and optionally header/query name and value) is matched against these patterns. You can use Regex flags where the UI or API supports them.

Common Regex Flags

Path pattern examples

Paths are the request path after the proxy base (e.g. /users, /2.0/Invoices/123). Use anchors so patterns match exactly what you intend.

Presence

• Must exist — The path must match the regex (use for “allow/deny this path”).
• Must not exist — The path must not match the regex (use to exclude paths).

Regex flags (when available) — See Common Regex Flags above. For paths, i (case insensitive) is often useful so ^/users.*$ matches /Users, /USERS/1, etc.

Header check examples

Header checks use a header name pattern and a header value pattern (both regex). Use Presence to require the header to match (present) or to be absent (must not exist).

Use the Flags field (e.g. i) where supported so name/value matching is case-insensitive if needed.

Query parameter check examples

Query checks use a parameter name pattern and a parameter value pattern (both regex).

Quick reference: copy-paste path patterns

^/users.*$
^/2\.0/Invoices.*$
^/api/.*
^/health$
^/(users|accounts|billing)(/|$)
\.(json|xml)$

• Use Must exist to allow or deny requests whose path matches the pattern.
• Use Must not exist to allow or deny requests whose path does not match.

Rule examples

Allow only GET and POST

Effect: Allow · Priority: 100 · Methods: GET, POST. Use with default Deny to allow only read and create operations.

Block admin access

Effect: Deny · Priority: 900 · Path: /admin (present). Blocks all requests to paths containing /admin.

Require API version header

Effect: Deny · Priority: 500 · Header: X-API-Version value ^[2-9]\. (absent = deny). Denies requests that don’t include a version 2.x or higher header.

Allow specific user paths

Effect: Allow · Priority: 600 · Methods: GET · Path: ^/api/users/[0-9]+$ (present). Allows GET to endpoints like /api/users/123.

Block debug mode

Effect: Deny · Priority: 800 · Query: debug = true (present). Denies any request with ?debug=true.

Where to configure rules

From each of these you can view rules, add new rules, edit existing rules, and delete rules.

Troubleshooting

Request unexpectedly denied

1. Check if any credential-level (or target-level) deny rules match the request.
2. Verify the default rule effect (Allow vs Deny) for the proxy/credential.
3. Check rule priorities — higher priority rules are evaluated first.
4. Review path patterns for unintended matches.

Request unexpectedly allowed

1. Check if an allow rule is overriding your expected deny.
2. Verify rule priorities and that all matching criteria are specified.
3. Confirm the default rule effect.

Rules not working

1. Confirm the rule is saved and appears in the rules list.
2. Ensure regex patterns are valid (see Common Regex Flags and path examples).
3. Set priority appropriately and verify the effect (Allow/Deny).

Security considerations

1. Defense in depth — Use rules at multiple levels (credential, proxy, target) for critical controls.
2. Deny by default — For sensitive resources, set default to Deny and allow only what’s needed.
3. Regular audits — Periodically review rules for appropriateness and removal of unused rules.
4. Logging — Monitor denied requests to detect misuse or misconfiguration.
5. Testing — Test rule changes in a non-production environment first.

Next steps