Redaction Policies

Redaction policies remove or mask sensitive fields in webhook payloads before they hit Hookbase storage, your destinations, or both. Unlike Field Encryption — which is reversible — redaction is one-way: the original value is gone for good. That's what unlocks HIPAA, PCI, and similar use cases where regulators treat encrypted-at-rest sensitive data as still in scope.

Available on Pro and Business plans.

How it fits

Feature	Storage	Reversibility	Use when
Field Encryption	AES-256 ciphertext	Reversible (decrypted at delivery)	You need the value at the destination but want it encrypted at rest.
Redaction (this page)	Stripped or masked	One-way	The value should never exist in Hookbase or never leave it for a specific destination.

Scopes

Each policy declares a scope:

Scope	When it runs	What it protects
`storage`	At ingest, before R2 + database write	Hookbase never sees the original value after ingest. Replays send the redacted form.
`delivery`	In the delivery worker, before each outbound request	Hookbase keeps the original for replay/debugging, but downstream destinations only see the redacted form.
`both` (default)	Both of the above	Maximum protection. Recommended starting point.

Rule shape

A policy contains up to 50 rules. Each rule has a match and an action:

Match types

Type	Value	Example
`field_name`	A key name. Matches at any depth.	`ssn`, `password`, `api_key`
`path`	Dotted path with optional `[n]` indices. Leading `$.` is allowed.	`user.ssn`, `payments[0].card_number`
`regex_value`	JS regex source. Tested against string values, not keys.	`\d{3}-\d{2}-\d{4}` (SSN-like)
`header`	Header name, case-insensitive. Only applies at storage scope today.	`Authorization`

Actions

Action	Effect
`redact`	Replace the value with `[REDACTED]`.
`mask`	Keep the last N characters (default 4); replace the rest with `*`. Useful for card numbers.
`hash`	Replace with the SHA-256 hex digest. Preserves uniqueness for joins/dedup.
`remove`	Delete the key entirely (no trace it ever existed).

Configuration

Via dashboard

Settings → Redaction
Click New policy
Name the policy, choose a scope, add rules
Use the Test with sample payload panel to verify the rules behave as expected before saving

Via API

curl -X POST "https://api.hookbase.app/api/organizations/{orgId}/redaction-policies" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PII default",
    "scope": "both",
    "rules": [
      { "match": { "type": "field_name", "value": "ssn" }, "action": { "type": "redact" } },
      { "match": { "type": "path", "value": "payment.card_number" }, "action": { "type": "mask", "keepLastN": 4 } },
      { "match": { "type": "regex_value", "value": "[\\w.+-]+@[\\w.-]+\\.[a-z]{2,}", "flags": "i" }, "action": { "type": "hash" } }
    ]
  }'

Precedence

When multiple policies match the same source — e.g. an org-wide policy plus a source-specific override — all rules are unioned. We chose union over override because it's the safer default: adding a source-specific policy can never accidentally undo redaction the org enforced.

Audit trail

Every event records whether redaction fired:

redaction_applied — boolean
redaction_policy_ids — array of policy IDs that fired

These are visible on the event detail page so support can answer "why is field X missing here?" without ever logging the redacted value itself.

Replay implications

Replays send whatever is in storage. If a policy with scope: storage (or both) stripped a field, that field is gone — replay sends the redacted form. The replay UI shows a banner when an event has redaction applied so you don't get blindsided.

Cache invalidation

Policy lookups are cached in KV for up to 5 minutes per source. When you create, edit, or delete a policy, source-specific caches are busted immediately, but org-wide policies (no sourceId) can lag by up to the cache TTL. Time-sensitive rollouts should use a source-specific policy.

Limitations (v1)

Header redaction runs only at storage scope. Outbound headers (auth, custom) are not redacted at delivery.
Warehouse destinations (S3/R2/GCS/Azure) apply delivery-scope policies, but only when a sourceId is present on the queue message — older queued messages from before this feature was deployed will not have it.
Non-JSON payloads are skipped at delivery time (storage redaction only applies to JSON-parsable bodies).

Redaction Policies

Available on Pro and Business plans.

How it fits

Feature	Storage	Reversibility	Use when
Field Encryption	AES-256 ciphertext	Reversible (decrypted at delivery)	You need the value at the destination but want it encrypted at rest.
Redaction (this page)	Stripped or masked	One-way	The value should never exist in Hookbase or never leave it for a specific destination.

Scopes

Each policy declares a scope:

Scope	When it runs	What it protects
`storage`	At ingest, before R2 + database write	Hookbase never sees the original value after ingest. Replays send the redacted form.
`delivery`	In the delivery worker, before each outbound request	Hookbase keeps the original for replay/debugging, but downstream destinations only see the redacted form.
`both` (default)	Both of the above	Maximum protection. Recommended starting point.

Rule shape

A policy contains up to 50 rules. Each rule has a match and an action:

Match types

Type	Value	Example
`field_name`	A key name. Matches at any depth.	`ssn`, `password`, `api_key`
`path`	Dotted path with optional `[n]` indices. Leading `$.` is allowed.	`user.ssn`, `payments[0].card_number`
`regex_value`	JS regex source. Tested against string values, not keys.	`\d{3}-\d{2}-\d{4}` (SSN-like)
`header`	Header name, case-insensitive. Only applies at storage scope today.	`Authorization`

Actions

Action	Effect
`redact`	Replace the value with `[REDACTED]`.
`mask`	Keep the last N characters (default 4); replace the rest with `*`. Useful for card numbers.
`hash`	Replace with the SHA-256 hex digest. Preserves uniqueness for joins/dedup.
`remove`	Delete the key entirely (no trace it ever existed).

Configuration

Via dashboard

Settings → Redaction
Click New policy
Name the policy, choose a scope, add rules
Use the Test with sample payload panel to verify the rules behave as expected before saving

Via API

curl -X POST "https://api.hookbase.app/api/organizations/{orgId}/redaction-policies" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PII default",
    "scope": "both",
    "rules": [
      { "match": { "type": "field_name", "value": "ssn" }, "action": { "type": "redact" } },
      { "match": { "type": "path", "value": "payment.card_number" }, "action": { "type": "mask", "keepLastN": 4 } },
      { "match": { "type": "regex_value", "value": "[\\w.+-]+@[\\w.-]+\\.[a-z]{2,}", "flags": "i" }, "action": { "type": "hash" } }
    ]
  }'

Precedence

Audit trail

Every event records whether redaction fired:

redaction_applied — boolean
redaction_policy_ids — array of policy IDs that fired

These are visible on the event detail page so support can answer "why is field X missing here?" without ever logging the redacted value itself.

Header redaction runs only at storage scope. Outbound headers (auth, custom) are not redacted at delivery.
Warehouse destinations (S3/R2/GCS/Azure) apply delivery-scope policies, but only when a sourceId is present on the queue message — older queued messages from before this feature was deployed will not have it.
Non-JSON payloads are skipped at delivery time (storage redaction only applies to JSON-parsable bodies).

Redaction Policies

How it fits

Scopes

Rule shape

Match types

Actions

Configuration

Via dashboard

Via API

Precedence

Audit trail

Replay implications

Cache invalidation

Limitations (v1)

See also

Redaction Policies

How it fits

Scopes

Rule shape

Match types

Actions

Configuration

Via dashboard

Via API

Precedence

Audit trail

Replay implications

Cache invalidation

Limitations (v1)

See also