Response Actions

Response Actions are WHEN → THEN automations: when a trigger condition is met, WebDecoy executes the actions you’ve configured, pushing a block to your WAF or notifying your systems.

The current Enforcement policy screen makes route scope and trust requirements explicit before a rule can affect traffic.

For threat-scoring and enforcement capabilities, see the Response Rules product overview.

They have their own page under Enforcement: click Enforcement in the sidebar, then the Actions tab (/enforcement/actions). The Enforcement page is now a set of routed sub-pages, and each one owns a different job:

Tab	What lives there
Overview (/enforcement)	the Monitor/Enforce switch and its readiness checks, the decision queue, and what the loop actually did
Policy (/enforcement/policy)	token-enforced routes and their minimum trust grades, the paths nothing is scoping, and the tokenless-client allowlist
Actions (/enforcement/actions)	Response Actions, the subject of this page
Setup (/enforcement/setup)	the one-time wiring: WAF connections, browser verification, the edge validator
History (/enforcement/history)	the enforcement audit log

Older links still work: /response-actions redirects to the Actions tab, and bookmarked ?tab= URLs forward to the sub-page that replaced them.

Anatomy of a Response Action

Each Response Action has a name, an enabled toggle, one trigger, and one or more actions.

Triggers

Trigger	Fires when
A confirmed rotating actor	An actor is confirmed rotating across multiple IP addresses with high aggregate threat
A high-risk detection	A single detection meets your score threshold (default 80)
Any detection	Every detection

Actions

Action	What it does	Requires
Block actor at WAF	Pushes a fingerprint (JA4) rule to your connected WAF, blocking the actor across every IP it rotates through	A connected AWS WAF integration, or Cloudflare with Bot Management (see below) · rotating-actor trigger only
Block IP	Adds an IP address to your WAF’s block list, with an automatic expiry. On a per-detection trigger it is the detection’s IP; on the rotating-actor trigger it is every IP the actor was observed on	A connected AWS WAF or Cloudflare integration
Webhook	POSTs a JSON event to an https:// URL you provide	None beyond the plan (see below)
Email	Emails a recipient you name when an actor is confirmed rotating	Rotating-actor trigger only

Email is offered only on the rotating-actor trigger, and the API refuses an email action on the other triggers. Per-detection email is deliberately not delivered; the weekly digest carries that information instead.

Saving an enabled Response Action that has actions requires a paid plan or an active trial; on Free the API answers 402 upgrade_required. Disabled rules can still be drafted, edited and deleted. See Plans and billing.

The editor shows which WAFs your organization has connected, so block actions are never a black box: if no WAF is connected, connect one under Integrations first.

Why “Block actor at WAF” requires the rotating-actor trigger

A fingerprint rule blocks every client that shares the fingerprint, and real browsers share fingerprints with each other. WebDecoy therefore only offers fingerprint blocking for confirmed rotating actors (a pattern of behavior no legitimate user population produces) and never from a single detection. Per-detection triggers can block the individual IP instead, which is safe because it’s scoped to one address and expires automatically.

On Cloudflare, fingerprint rules need Bot Management

The rule is built on cf.bot_management.ja4, which Cloudflare gates behind Bot Management, an Enterprise add-on. On Free, Pro and Business zones Cloudflare refuses the rule and no configuration works around it. Block IP is unaffected, and so is session clearance, which needs no Cloudflare add-on and holds up better against IP rotation anyway.

Run the Cloudflare zone check (Test rule permissions) on Enforcement → Setup, in the WAF connections step, to see what your zone actually supports. Details: Fingerprint rules need Bot Management.

Safety defaults

Actor-level enforcement is designed to fail safe:

• Fingerprint rules are confined to the confirmed-rotating-actor trigger, as above.
• IP blocks expire automatically: after the AWS WAF integration’s block duration if you set one, otherwise after 24 hours. IPs rotate; there’s no value in blocking an address forever, and expiry protects future legitimate holders of that address.
• Monitor before you block: with the organization in Monitor mode, WebDecoy still records the composite signatures it would enforce, and pushes none of them. On AWS WAF, set the integration’s Action to Count and the rule WebDecoy adds for its IP set counts matches instead of blocking them. (That setting does not change the pushed fingerprint rule, which is always Block.)

Setting up a Response Action

1. Go to Enforcement in the sidebar and open the Actions tab
2. Click New action
3. Name it (e.g., “Block rotating scrapers”)
4. Choose the trigger. For actor-level blocking, choose A confirmed rotating actor
5. Enable the actions you want
6. Click Create action

What runs automatically today

An enabled Response Action is evaluated on every new detection (for the high-risk and any detection triggers) and whenever an actor is confirmed rotating. What happens next depends on the action type:

• Webhook and Email actions are delivered automatically as soon as their trigger fires.
• Block IP and Block actor at WAF are score-driven WAF changes, and those are currently withheld. Automatic blocking waits until the deployed scorer version has been calibrated and WebDecoy turns it on; until then a blocking action is recorded as withheld and nothing is pushed to your WAF. A block applied later also requires that every detection behind it was scored by the current scorer version.

One automatic WAF path is separate from Response Actions and is not held by that calibration gate: when the organization is in Enforce mode with Cloudflare connected, WebDecoy deploys a composite Cloudflare rule (the actor’s JA4 and its dominant ASN) for each actor that qualifies as a confirmed rotator, whether or not a Response Action exists. It never pushes a bare fingerprint on this path, it skips browser-like and shared JA4s, and it withdraws those rules when the organization returns to Monitor or the plan no longer includes enforcement. Like every JA4 rule on Cloudflare, it needs Bot Management. See Cloudflare.

You do not need to wait to block by hand. An IP block you apply yourself with Block an address on an integration’s page (AWS WAF, Cloudflare, Fastly or Vercel) is not held by this gate, and neither are session clearance or denying an actor’s clearance on the actor’s page.

Test detections (the reserved test User-Agent) and your own canary visits never trigger Response Actions.

Webhook payloads

A per-detection trigger (high-risk or any detection) sends:

{
  "event": "detection",
  "detection_id": "<uuid>",
  "organization_id": "<uuid>",
  "ip": "203.0.113.7",
  "ja4": "t13d1516h2_8daaf6152771_02713d6af862",
  "unified_score": 86
}

The rotating-actor trigger sends:

{
  "event": "rotating_actor_confirmed",
  "actor_id": "<uuid>",
  "organization_id": "<uuid>",
  "ja4": "t13d1516h2_8daaf6152771_02713d6af862",
  "distinct_ip_count": 14,
  "aggregate_threat": 91,
  "detection_count": 37
}

Illustrative example: the values above are made up; the field names are the ones WebDecoy sends.

Starting from what prompted it

A rule is usually wanted at the moment something bothers you, not while browsing a settings list, so the editor is reachable from the evidence:

• Respond to detections like this, in the detection flyout.
• Respond to actors like this, on an actor’s page, next to the deny control.

Opened either way, the editor names what it was opened from and preselects the trigger that origin implies. An actor gets the confirmed-rotating trigger, which is the one case fingerprint blocking is safe for. A detection gets a score threshold drawn from what that detection actually scored, rounded down to a band so the rule reads as “ones like this” rather than as one sample’s exact number. Everything is editable before you save.

The values a WAF rule needs

The detection flyout can copy the identifiers enforcement keys on, in the order they are usually reached for: the IP address, the JA4 handshake fingerprint, the ASN, the clearance fingerprint, and the user agent. Only values actually present on that detection are offered, because a copy button that yields nothing tells you a value exists when it does not.

Two of those are the identities enforcement acts on. JA4 is what a fingerprint rule blocks at your WAF. The clearance fingerprint is what a deny binds to, and it survives the IP rotation that makes an address-based block worthless. When a detection carries its own clearance fingerprint, that value is preferred over the actor’s rolled-up one: the rollup holds whatever is minting tokens now, while the detection holds what arrived with the request on screen.

Cloudflare status

Cloudflare rule pushes are live. Cloudflare retired the legacy Firewall Rules API this integration originally used, and WebDecoy has been rebuilt on the Rulesets API.

One limit is worth knowing before you configure anything: fingerprint (JA4) rules need Cloudflare Bot Management, an Enterprise add-on. See the note above. block_ip and session clearance have no such requirement. AWS WAF has no equivalent gate.

Beyond WAF rules: session clearance

WAF rules are the right tool for datacenter and scripted bots. For browser-shaped traffic (real browsers automated from residential IPs, where no fingerprint or IP rule is safe), WebDecoy enforces with session clearance: real sessions earn a signed token, enforced routes require it, and a decoy hit revokes it durably on every IP. If you’re protecting login, checkout, or scraped endpoints, set it up alongside your Response Actions. It needs an edge validator (Cloudflare, AWS CloudFront or Netlify).

API access

GET    /api/organizations/{organization_id}/response-actions
POST   /api/organizations/{organization_id}/response-actions
PUT    /api/organizations/{organization_id}/response-actions/{id}
DELETE /api/organizations/{organization_id}/response-actions/{id}

These are dashboard API routes: they require a signed-in user’s session token. API keys do not authenticate them.

---

Next Steps

• Actors: the identity model behind actor-level blocking
• AWS WAF Integration: set up the WAF connection block actions push to
• Webhook Integration: event payloads for custom automation