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. They live on the Enforcement page (click Enforcement in the sidebar), below the setup pipeline.

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 · rotating-actor trigger only
Block IP	Adds the detection’s IP address to your WAF’s managed block list, with an automatic expiry	A connected WAF integration
Webhook	Sends the event to a URL you provide	—
Email	Emails your team when the trigger fires	—

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.

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 — the duration is set on your WAF integration (default 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 — the AWS WAF integration’s action can be set to Count (Monitor Only), which logs what would be blocked without blocking it. Start there, review, then switch to Block.

Setting up a Response Action

1. Go to Enforcement in the sidebar and scroll to Response actions
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. Save — the action runs automatically from then on

Cloudflare status

Cloudflare rule pushes are temporarily paused: Cloudflare retired the legacy Firewall Rules API that the integration used, and the rebuild on Cloudflare’s newer Rulesets API is in progress. AWS WAF pushes are unaffected, and so is session clearance — its edge validator is a separate mechanism from rule pushes.

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 on a Cloudflare-proxied site, set it up alongside your Response Actions.

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}

See API Keys for authentication.

---

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