How rules work
Rules let you attach ordered, conditional behavior to a CDN property. The Paradarum edge (OpenResty) evaluates each rule against incoming requests and applies the matching ones to the request or response.
The two shipped rule types
Today the rules engine ships exactly two rule types:
| Rule type | RuleType value | What it does |
|---|---|---|
| Cache rule | 0 | Controls cache TTL and per-URL cache features for matching URLs. See Cache rules. |
| Header rule | 1 | Adds, sets, or deletes an HTTP header on the request or response. See Header rules. |
Both rule types share the same matching mechanism — a single URL match operator — and the same lifecycle controls described below.
:::danger Redirect, reverse-proxy, and static-response rules are not available Some scaffolding exists internally (and in the frontend) for redirect, reverse-proxy, static-response, and rewrite rule types. None of these are wired into the product and they cannot be created or edited. Treat them as roadmap only — do not rely on them. The only usable rule types are Cache rule and Header rule. :::
Where rules live
Rules attach to a single property. In the Paradarum panel, open Properties → (select a property) → Detail → Rules. The Rules tab gives you a list view, a create flow, and an edit flow per rule.
When you create a rule, a Select Rule Type dialog offers two cards — Cache Rule and Header Rule — and your choice determines which configuration form you see.
Ordering
Every rule carries an integer order. Lower order runs first. This lets you control precedence — for example, applying a broad cache rule before a more specific override, or stripping a header before another rule adds it.
In the panel you reorder rules by drag-and-drop. Each drag persists the changed rows and shows a confirmation snackbar.
:::info Reordering is one PUT per rule — there is no batch endpoint
There is no dedicated reorder endpoint. The panel (and any API client) reorders by issuing an individual PUT for each rule whose order changed. Because each update is a separate call, a partial failure is possible; the panel surfaces this with a "Some rule order updates failed" message. See the API reference for the per-rule update endpoints.
:::
Enable and disable
Each rule has an isEnabled toggle. Disabling a rule stops it from being applied without deleting it, so you can keep a rule's configuration around and switch it back on later.
System rules
Rules also carry an IsSystem flag. System rules are managed by the platform — for example, the rules that back a live-stream property — and are:
- read-only — you cannot edit or delete them from the panel, and
- hidden by default — they are filtered out of the list unless you explicitly include them.
For managed properties (such as one backing a live stream), the panel shows system rules read-only with a one-line summary, for example cache 3600s · /hls/ or response header · Access-Control-Allow-Origin: *.
When listing rules through the API, system rules are excluded by default. Pass includeSystem=true to see them:
# Default — excludes system rules
curl -H "X-Api-Key: pdm_YOUR_KEY" \
"https://api.paradarum.com/api/Property/42/rules"
# Include platform-managed system rules
curl -H "X-Api-Key: pdm_YOUR_KEY" \
"https://api.paradarum.com/api/Property/42/rules?includeSystem=true"
How changes reach the edge
Changes are near-real-time, not instant. The edge polls configuration rather than receiving a synchronous push — creating, editing, deleting, or reordering a rule updates the stored configuration, and the OpenResty edge picks it up on its next poll.
Because propagation is poll-based, allow a short delay after saving before validating behavior at the edge.
Next steps
- URL match operators — the five ways a rule can match a request URL.
- Cache rules — TTL and per-URL cache features.
- Header rules — add, set, or delete request/response headers.
- CMS presets — ready-made rule sets for common platforms.