Skip to content
HookDeploy
HookDeployDocumentation
On this page ↓
Getting startedIntroduction

What HookDeploy is, who it's for, and the core concepts behind webhook capture and replay.

→Getting startedQuickstart

From signup to your first captured webhook in under five minutes.

→Getting startedYour first endpoint

Create an endpoint, copy its URL, send test requests, and read the request inspector.

→Core conceptsForwarding

Forward captured webhooks to one or more destinations, with optional payload transformation.

→Core conceptsTransformations

Reshape webhook payloads before forwarding with the visual editor, 35 built-in formatters, conditions, and form-encoded support.

→Core conceptsPrivacy filters

Reshape or redact webhook payloads before HookDeploy stores them ΓÇö without changing what forward destinations receive.

→Core conceptsCustom Responses

Override the HTTP response HookDeploy returns to webhook senders. Set a custom status code, response body, and dynamic variables for testing and mocking.

→Core conceptsEndpoint security

Restrict access to your HookDeploy endpoints with IP allowlists and secret token authentication.

→
↑↓ navigateEnter openEsc close

Privacy filters

Reshape or redact webhook payloads before HookDeploy stores them ΓÇö without changing what forward destinations receive.

Privacy filters reshape or redact the payload before it is written to HookDeploy storage. Use them when you need history, replay, and debugging without keeping full PII in your captured archive.

Configure them in Endpoint → Settings → Stored payload filters.

The most important rule

Forwarding always receives the original, unfiltered payload.

Privacy filters never rewrite what your destinations see. Destination transformations are a separate, per-destination pipeline that runs on the original inbound body.

PathPayload
Forward destinationsOriginal request body (plus any destination transform you configure)
Stored request history / replay sourceResult of privacy filters (then sanitization and encryption)

If you need destinations to receive a redacted body, configure a destination transformation ΓÇö not a privacy filter.

Fail-closed behaviour

Read this before you enable filters on a production endpoint.

When a privacy filter is configured:

  • If the filter cannot be applied, HookDeploy does not store the original payload. Storage fails closed so unfiltered PII is not written to disk.
  • Non-JSON bodies (and bodies that cannot be parsed as JSON or form-urlencoded for the filter pipeline) are not stored as the original when a filter is configured ΓÇö a fail-closed sentinel is stored instead.
  • Transform errors at storage time mean no usable filtered payload is kept. The live editor may still show a partial preview to help you fix rules; production storage does not keep that partial result when errors occur.

Enabling privacy filters to protect PII can also mean empty or sentinel history when a rule is wrong. Test against a captured sample before you rely on the archive.

What you can do

Privacy filters use the same transformation engine as forwarding:

  • Passthrough (store all fields, filter selected) or allowlist (store only selected fields)
  • Field rules, combine rules, conditions, and formatters
  • Live preview against your latest captured request

See Transformations for operators, formatters, and limits.

Stored body format

Each endpoint has a Stored body format control next to privacy filters:

SettingBehaviour
Original (default)Keep the arrival Content-Type when the stored body can still be represented that way (for example form-urlencoded stays form when flat)
JSONNormalize form-encoded (and similar) bodies to JSON for storage

If a privacy filter produces nested output from a form payload, storage falls back to JSON even when Original is selected ΓÇö form encoding cannot represent nested objects.

Plan gating

PlanPrivacy filters
FreeNot available
StarterAllowlist mode; formatters limited to mask, hash, set_null, set_value (and strip/remove)
Pro and abovePassthrough mode and every formatter (including conditions, combine rules, and advanced string/date/JSON formatters)

Forwarding transformations remain Starter+ with no per-formatter gate. Privacy filters are stricter on Starter because they change what is retained.

Order relative to sanitization

For each captured request with a privacy filter configured:

  1. Privacy filter runs on the parsed body (fail-closed on error)
  2. Header / body-key sanitization runs on the result (redact configured keys)
  3. The sanitized body is encrypted and written to storage

Sanitization cannot ΓÇ£rescueΓÇ¥ a failed privacy filter ΓÇö fail-closed already replaced the body with a sentinel before sanitization runs.

Header and body-key sanitization are documented under Endpoint security.

When to use privacy filters vs destination transforms

GoalUse
Destinations must not see PIIDestination transformation (or don’t forward that field)
Destinations need the full payload, but storage should not keep itPrivacy filters
BothPrivacy filters for storage and destination transforms for each forward URL

Next steps