Endpoint security

HookDeploy endpoints are publicly accessible URLs by design — any service can send webhooks to them. For production use, you can restrict access using two security mechanisms: IP allowlists and secret token authentication.

Both features are available on Starter and above. Configure them in your endpoint’s Settings tab under the Security section.

Secret token authentication

Require a secret token on every incoming request. Requests without a valid token receive a 401 Unauthorized response and are logged as blocked attempts.

How token authentication works

1. Generate a token in your endpoint’s Security settings
2. Copy the token — it’s only shown once
3. Configure your webhook sender to include the token

The sender must include the token in one of two ways:

As a header (recommended):

X-HookDeploy-Token: hd_ep_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

As a query parameter:

https://hookdeploy.dev/h/your-slug?token=hd_ep_xxxx

The header method is recommended — query parameters may appear in server logs.

Token format

Tokens are prefixed with hd_ep_ followed by 32 random characters. They are stored as SHA-256 hashes — the plaintext token is never stored and cannot be recovered. If you lose the token, generate a new one.

Regenerating a token

Generating a new token immediately invalidates the previous one. Update your webhook sender before regenerating to avoid dropped webhooks.

Revoking a token

Revoking removes the token requirement entirely. All requests will be accepted again until a new token is generated.

IP allowlist

Only accept requests from specific IP addresses or CIDR ranges. Requests from unlisted IPs receive a 403 Forbidden response and are logged as blocked attempts.

How IP allowlisting works

1. Go to your endpoint’s Security settings
2. Enable the IP allowlist
3. Add IP addresses or CIDR ranges

When the allowlist is empty, all IPs are accepted (same as disabled). When the allowlist has entries, only listed IPs are accepted.

Quick add — provider IP ranges

HookDeploy includes pre-configured IP ranges for common webhook providers. Click the provider button to add all their IPs at once:

Custom IPs and CIDR ranges

Add any IPv4 address or CIDR range:

Individual IP:  1.2.3.4
CIDR range:     192.168.1.0/24

IPv6 addresses in IPv4-mapped format (e.g. ::ffff:1.2.3.4) are automatically normalized to their IPv4 equivalent.

Important: private/test endpoints

Don’t enable IP allowlists on development or test endpoints — your local IP changes frequently and you’ll lock yourself out. Use IP allowlists only on production endpoints receiving webhooks from known providers.

Blocked requests log

Every blocked request is logged with:

• Timestamp
• Source IP address
• HTTP method
• Block reason (invalid token or IP not allowed)

View blocked requests in the Blocked tab on your endpoint detail page. The tab only appears when at least one security feature is enabled.

Blocked request payloads are never stored — only the metadata above is retained.

Endpoint slugs

New endpoints use 16-character slugs on every plan. Treat the URL as an identifier, not as an authentication credential; enable a secret token and IP allowlist for production sources when available.

Using token + IP together

You can enable both security features simultaneously. A request must pass both checks to be accepted:

1. Token check runs first
2. IP check runs second
3. Both must pass

This is the most secure configuration for production endpoints.

Payload sanitization

HookDeploy redacts sensitive authentication headers before storage by default on every plan. This protects credentials from being exposed to organization members or anyone with access to captured requests.

What gets redacted

The following headers are automatically redacted:

Redacted values are replaced with [SANITIZED] in the stored payload and dashboard display.

Signature headers preserved for verification

HookDeploy preserves common HMAC signature headers by default so your destination can verify webhook authenticity:

• X-Stripe-Signature
• X-Hub-Signature-256 (GitHub)
• X-Shopify-Hmac-Sha256
• X-Twilio-Signature
• X-Svix-Signature

Treat captured requests as sensitive data even when these headers do not contain the provider’s signing secret.

Forwarding behavior

Sanitization applies to the stored captured representation. Forwarding uses the request received for delivery, subject to your destination configuration and any configured transformation.

Disabling sanitization

Starter and higher plans can opt out per endpoint in Settings → Security → Payload sanitization. Opt-outs are audited. Check the current dashboard or pricing page for availability before changing this protection.

When you disable sanitization:

• A warning dialog explains the security implications
• Your acknowledgement is recorded in the audit log with your user ID and timestamp
• A warning banner appears on the endpoint until sanitization is re-enabled

Re-enabling sanitization does not retroactively redact previously stored requests. Only new requests captured after re-enabling are sanitized.

Body key sanitization

Body sanitization applies only when you configure it for an endpoint. It redacts selected fields from JSON request bodies before storage, which is useful for payloads that include passwords, refresh tokens, or other credentials.

When body sanitization is active, HookDeploy adds these default redacted keys: password, secret, client_secret, private_key, refresh_token, auth_token, credentials, passphrase, cvv, ssn

Add custom keys in Settings → Security → Body key sanitization.

Note: Common fields like token and api_key are not in the default list because they are often safe identifiers (e.g. Stripe tokens, pagination tokens). Add them manually if your payloads use these as credential fields.

Audit log

Sanitization setting changes are recorded in the endpoint audit log with the acting user and timestamp.

Encryption and organization isolation

Stored payloads are encrypted at rest with AES-256-GCM. Each organization has scoped data-encryption keys (DEKs), and active keys rotate weekly. Authorization checks keep endpoint, request, and key access isolated to the owning organization.

Temporary support access

HookDeploy personnel do not receive standing access to organization payloads. Exceptional support or incident access requires an explicit break-glass grant with a selected expiry of 24 hours, 48 hours, or 7 days. Grants are temporary and audited.

Security checklist for production endpoints

• Enable secret token authentication
• Store the token securely (password manager, secrets manager)
• Configure your webhook sender to include the token header
• Add your provider’s IP range to the allowlist
• Test with a real webhook to confirm it passes
• Check the Blocked tab — verify no legitimate requests are blocked
• Rotate the token periodically (every 90 days recommended)