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 and 23 built-in formatters.

→Core conceptsEndpoint security

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

→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 conceptsResponse Delay

Add an artificial delay before HookDeploy responds to a webhook sender. Useful for testing timeout handling and retry logic.

→
↑↓ navigateEnter openEsc close

Forwarding

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

HookDeploy can automatically forward every captured webhook to one or more destination URLs. Use forwarding to proxy webhooks to your production server, notify multiple services simultaneously, or transform payloads before they reach your infrastructure.

How forwarding works

When a webhook arrives at your HookDeploy endpoint:

  1. The payload is captured and stored (this always happens first)
  2. HookDeploy forwards the request to each enabled destination in parallel
  3. Forward results (status code, response time, errors) are recorded per destination
  4. Your dashboard shows the forward status next to each captured request

The original webhook sender receives a 200 OK immediately after capture — they never wait for forwarding to complete.

Multiple destinations

Each endpoint supports multiple named forward destinations. Examples:

  • Production server — your real webhook handler
  • Slack alerts — a Slack incoming webhook URL for team notifications
  • CRM — your CRM’s webhook endpoint for customer event tracking
  • Analytics — a data pipeline ingestion endpoint

All destinations receive the webhook in parallel. If one destination fails, the others are unaffected.

Available on Starter (5 destinations) and Team (unlimited).

Destination configuration

Each destination has:

  • Name — a label for your team (“Production server”, “Slack alerts”)
  • URL — must be HTTPS
  • Method override — optionally change the HTTP method (e.g. POST → PUT)
  • Header injection — add authentication headers your server requires
  • Payload transformation — modify the payload before forwarding
  • Enabled toggle — pause a single destination without affecting others

Configure destinations in the dashboard under Endpoint → Settings → Forward destinations.

Header injection

Add headers to every forwarded request. The most common use case is authentication:

Authorization: Bearer your-server-token
X-Tenant-ID: acme-corp

Injected headers override matching headers from the original request. HookDeploy always adds these headers and they cannot be overridden:

  • x-hookdeploy-forward: 1
  • x-hookdeploy-destination: {destination name}
  • x-hookdeploy-request-id: {request id}

Availability is plan-controlled. Check the current dashboard or pricing page for the features enabled for your organization.

Payload transformation

Transform the webhook payload before it reaches your destination. Use the visual editor to:

  • Strip PII — remove sensitive fields like customer emails before forwarding to analytics
  • Rename fields — map data.amount to payment.amount to match your server’s schema
  • Format values — convert 4200 (cents) to "$42.00" (dollars)
  • Add static fields — inject {"source": "stripe", "version": "2"} into every payload
  • Allowlist fields — forward only specific fields, drop everything else

See Transformations for the full formatter reference and recipes.

Transformation availability is plan-controlled. Check the current dashboard or pricing page for the current plan offering.

Transformation modes

Passthrough mode (default): All fields are forwarded. Apply transforms to specific fields only. Use this when you want to forward most of the payload and only modify a few fields.

Allowlist mode: Only fields you explicitly select are forwarded. Use this for strict PII control — nothing gets through unless you approve it.

Available formatters

FormatterInputOutput
cents_to_dollars4200"$42.00"
unix_to_iso1716912060"2024-05-28T14:01:00Z"
mask"john@example.com""joh*************"
hash"john@example.com""a1b2c3..." (SHA-256)
uppercase"hello""HELLO"
prefix"123""order_123"
set_nullanynull
…

Full formatter reference in Transformations.

Forward result tracking

Every forward attempt is recorded. In the request detail view, you can see:

  • Which destinations received the webhook
  • HTTP status code from each destination
  • Response time in milliseconds
  • Error message if the forward failed
  • Whether a transformation was applied

Destination response body capture

On Starter and above, you can opt in per forward destination to capture the destination’s HTTP response body (not just status code and response time). Enable Log response body on the destination in the dashboard.

Captured response bodies are encrypted at rest with the same per-organization keys as request payloads. They follow the same retention policy as captured requests and are purged when the parent request expires.

Retrieve captured bodies from the dashboard request detail view, or via the Requests API (GET .../forward-results/:forwardResultId/response). This applies to standard HTTPS URL destinations; tunnel-based destinations are not supported for response body capture today.

What gets forwarded

By default (no transformation configured), HookDeploy forwards the stored captured representation:

  • The captured HTTP method (or your override)
  • Captured headers, excluding proxy headers
  • Your injected headers (on top of originals)
  • The stored request body
  • Captured query parameters

Plus HookDeploy adds:

  • x-hookdeploy-forward: 1
  • x-hookdeploy-destination: {destination name}
  • x-hookdeploy-request-id: {request id}

Retry behavior

Each destination has retry controls. The maximum automatic retry count is plan-controlled: Free 0, Starter 3, Team 5, and Enterprise 10. Configure the available retry setting on the destination in the dashboard.

Standard HTTPS forwarding attempts use a 15-second delivery timeout. Failures and retry attempts are recorded per destination; you can also replay a captured request manually.

Next steps