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 Proxy Credential, Target Credential, Proxy, and Target levels.

How rules work

Evaluation order

Rules are evaluated across four independent scopes. All four scopes are evaluated simultaneously, and every scope must allow the request — a Deny from any single scope blocks the request, regardless of what the others decide.

Each scope is evaluated independently using its own configured rules and its own default effect. There is no priority or ordering between scopes — they are all equal gates.

Within a single scope

Within each scope, rules are sorted by priority (higher number = evaluated first). All rules that match the request are collected — not just the first. The outcome is then determined as follows:

Default behavior

Each scope has its own default effect: Allow or Deny. This only applies when no rule in that scope matches the request.

• 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

Proxy Credential rules apply to all requests made using that credential, regardless of which proxy or target is involved. Use them for caller-level policies — blocking methods or paths for a specific consumer.

Target Credential rules apply to all requests that use that target credential to reach the upstream API. Use them for upstream-level access policies tied to the authentication used with the target service.

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

Target rules apply to all requests destined for that target, regardless of which proxy sends them. Use them for platform-wide policies on a particular upstream service.

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 rules across all four scopes — a deny in any one of them (proxy credential, target credential, proxy, or target) will block the request.
2. Verify the default rule effect (Allow vs Deny) for each scope involved.
3. Check rule priorities — higher priority rules are evaluated first within a scope.
4. Review path patterns for unintended matches.

Request unexpectedly allowed

1. Check if an allow rule is matching before your intended deny rule (priority ordering within a scope).
2. Remember that all four scopes must deny to guarantee a block — if one scope allows and another denies, the deny wins. But if all four allow, the request passes.
3. Confirm the default rule effect for each relevant scope.

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 across all four scopes (proxy credential, target credential, proxy, target) for critical controls. A Deny at any scope blocks the request.
2. Deny by default — For sensitive resources, set the default effect to Deny and use Allow rules to permit only what is needed.
3. Scope your rules correctly — Target and target credential rules affect all proxies pointing at that target. Proxy credential rules affect all proxies using that credential. Use the narrowest scope that satisfies your requirement.
4. Regular audits — Periodically review rules for appropriateness and removal of unused rules.
5. Logging — Monitor denied requests to detect misuse or misconfiguration.
6. Testing — Test rule changes in a non-production environment first.

Next steps