Filter, deduplicate, and redact webhook events

Configure pre-execution filters, deduplication strategies, and PII redaction for incoming webhook events.

Goal

Reduce noise, prevent duplicate runs, and scrub sensitive fields before your workflow ever sees them. Each of the three advanced settings solves a specific problem and they can be combined freely.

When to use the advanced settings

You should look at the advanced settings when one of these things is true:

Duplicates — your provider retries failed deliveries and you're getting the same event multiple times
Noise — your trigger fires for events you don't actually care about (every Stripe webhook for every customer when you only care about one event type)
Sensitive data — the upstream payload contains PII or secrets that shouldn't end up in your run history

The advanced settings are configured under the Advanced Settings section of the trigger configuration panel. Click the trigger node, scroll down past the URL, secret, and curl command, and click Advanced Settings to expand the section.

Deduplicate identical events

Deduplication prevents the same logical event from triggering more than one workflow run within a configured time window.

When deduplication matters

Most webhook providers send retries when they don't get a fast 200 OK. If your workflow takes a few seconds to acknowledge or your network has a hiccup, the same event can arrive two or three times. Without deduplication, that means two or three workflow runs for one logical event — which is at best wasted compute and at worst a real bug if your action is not idempotent.

Deduplication is also useful for at-least-once delivery providers like Stripe and Shopify, which explicitly state they may send the same event more than once and recommend you handle it.

Choose a strategy

The trigger supports five deduplication strategies. Pick the one that matches what your provider sends:

Strategy	Use this when	What you configure
`Disabled`	Your workflow is fully idempotent and you don't care about duplicates	Nothing
`Event ID`	The provider sends a stable event ID in the body and you want TaskJuice to extract it automatically	Nothing — TaskJuice looks at the well-known field paths
`Payload Hash`	You want to dedupe on byte-identical bodies. Catches retries but not logically-equivalent events with different timestamps	Nothing
`Header Value`	The provider sends a stable idempotency key in a specific header (Stripe sends `Stripe-Idempotency-Key`, many APIs send `X-Idempotency-Key`)	The header name to read
`Expression`	You want to extract the dedup key from a specific field in the body using JSONPath	A JSONPath expression like `$.data.id`

For Stripe webhooks, use Header Value with Stripe-Idempotency-Key. For GitHub webhooks, use Header Value with X-GitHub-Delivery. For provider events that include an id field at the top level, use Expression with $.id.

Configure the dedup window

Once you pick a strategy, the Window (seconds) field appears. This is the time period during which a duplicate dedup key suppresses additional workflow runs.

Window	Use it when
60 (one minute)	Tight retry windows from well-behaved providers
3600 (one hour)	The default — catches most retry scenarios
86400 (24 hours)	At-least-once providers that may retry up to a day later

The maximum is 86,400 seconds (24 hours). The default is 3,600 seconds (one hour) when you enable deduplication for the first time.

What happens when a duplicate is detected

TaskJuice returns 409 duplicate request to the caller and does not create a workflow run. The provider treats this as a successful delivery (since it's not a 5xx) and stops retrying. The duplicate does not appear in your run history.

Verify dedup is working

Send the same request twice within the dedup window. The first should return 200 received; the second should return 409 duplicate request with the same error body shape. Only one run should appear in your history.

Filter events before they trigger workflows

Pre-execution filters let you accept the request, check the body against a condition, and skip the workflow run when it doesn't match. The request still returns 200, so the upstream system doesn't retry — but no workflow is created.

When filtering matters

Many providers fire webhooks for every event in a category, not just the ones you care about. Stripe sends charge.succeeded for every successful charge across your entire account; you might only want to react to charges over $100. GitHub sends issues events for opened, edited, closed, reopened, labeled, assigned, and a dozen other actions; you might only care about opened.

Filtering at the trigger means you don't have to add a Branch node at the start of every workflow to skip events you don't want. The skip happens before any workflow code runs, so you don't pay for compute on irrelevant events.

Configure a filter

Toggle the Pre-Execution Filter switch on. Two fields appear:

Field	Description
`Mode`	`Include` runs the workflow only when the expression is true. `Exclude` skips the workflow when the expression is true.
`Expression`	A JSONPath boolean expression evaluated against the parsed body

A typical include filter for "only large Stripe charges":

$.data.object.amount > 10000

A typical exclude filter for "skip GitHub bot users":

$.sender.type == 'Bot'

A combined filter using boolean operators:

$.event == 'checkout.completed' && $.data.amount > 5000

Verify the filter works

Send a request that matches the filter and confirm a run appears in your history. Send a request that doesn't match and confirm:

The response is 200 received (so the upstream system doesn't retry)
No run appears in the history

If runs are appearing for events that should have been filtered, check your expression syntax — JSONPath uses == for equality (not =) and string literals require quotes.

Filtered events return 200, not 422

TaskJuice intentionally returns 200 received for filtered events, not an error. This prevents the upstream system from retrying. If you want filtered events to return an error code, use a Branch node inside the workflow instead.

Redact sensitive fields

PII redaction replaces matching field values in the parsed body with redaction markers before the workflow runs. This is useful when the upstream payload contains sensitive data that shouldn't appear in your run history, your logs, or your downstream actions.

When PII redaction matters

If your workflow processes events that include personal information — email addresses, phone numbers, social security numbers, credit card details — you may have a compliance or contractual obligation to limit where that data appears. PII redaction lets you scrub specific fields at the trigger so the workflow never sees the original values.

This is particularly relevant for:

GDPR-bound workflows handling EU customer data
HIPAA-bound workflows handling US health data
Workflows that ingest webhooks for audit but don't need the sensitive fields downstream
Customer-facing workflows where the run history is visible to customer support

Configure redaction patterns

Toggle the PII Redaction switch on. A textarea appears for Field patterns:

ssn
credit.?card
email
phone.?number

Each line is a regular expression matched against field names in the parsed body. Matching field names get their values replaced with a redaction marker before the body reaches $trigger.

Limit	Value
Maximum patterns	50 per trigger
Maximum length per pattern	200 characters
Pattern format	Any valid JavaScript regular expression
Matching	Case-insensitive against field names (not values)

Common pattern starters

Pattern	Matches
`ssn`	`ssn`, `socialSecurityNumber` (because the pattern is a substring)
`credit.?card`	`creditCard`, `credit_card`, `creditcard`
`email`	`email`, `emailAddress`, `customerEmail`
`phone.?number`	`phoneNumber`, `phone_number`, `phonenumber`
`password`	`password`, `passwordHash`, `oldPassword`

If you need stricter matching, anchor the pattern: ^email$ matches only the literal field name email, not emailAddress.

Verify redaction is applied

Send a request with a payload that includes a sensitive field:

curl -X POST https://api.taskjuice.ai/webhooks/<your-token> \
  -H "Content-Type: application/json" \
  -d '{"event":"signup","email":"alice@example.com","userId":"u_123"}'

Open the run in your dashboard and inspect the trigger node's output. The email field's value should be replaced with a redaction marker; userId should be unchanged.

Redaction matches field names, not values

PII redaction only knows about field names. If a credit card number is embedded in a notes field, redaction won't catch it. For value-based redaction, use a Transform node after the trigger.

Combining the three settings

The three advanced settings run in this order:

Deduplication — checked first, before any parsing or workflow logic. Duplicate requests return 409 and never proceed.
Pre-execution filter — checked second, against the parsed body. Filtered events return 200 received and never proceed.
PII redaction — applied third, to events that pass dedup and filter. Redacted values appear in $trigger instead of the originals.

You can use any combination. A typical production webhook for a payment provider uses all three: dedup on Stripe-Idempotency-Key, filter to include only charge.succeeded events over $100, and redact the customer's email and address fields.

Send your first webhook — set one up before adding advanced settings
Authenticate your webhook — secure the trigger first, then add advanced behavior
Webhook trigger reference — every advanced field with type and default