Generic HTTP

Overview

Splithook works with any provider that sends HTTP webhooks — not just the five natively supported ones. For providers without built-in signing support, use passthrough or strip mode and rely on other security measures.

Pointing any provider at Splithook

The endpoint URL works with any HTTP client:

https://splithook.com/e/{slug}

• Accepts all HTTP methods (POST, PUT, PATCH, DELETE, GET).
• No IP allowlist — designed for external providers.
• No authentication required on the ingest side.
• Stores headers, method, and body exactly as received.

Security without signing

If your provider doesn't sign webhooks, you still have options:

Slug obscurity — The 8-character base32 slug has ~1 trillion combinations. It's not a secret, but it's not guessable by brute force either. Rotate it if you suspect it's been leaked.

IP filtering (self-hosted) — If you self-host Splithook, you can add IP allowlist rules at the reverse proxy level for providers that publish a static IP range.

HMAC via shared secret — Some providers let you configure a custom secret that they include in a header (e.g. X-Webhook-Secret: abc123). Use a filter to reject events without it:

headers['x-webhook-secret'] == 'abc123'

Non-JSON payloads

Splithook captures any body, but schema inference only works on valid JSON. For form-encoded or binary payloads:

• Headers and method are stored normally.
• The body is stored in Redis and visible in the raw body viewer.
• Schema inference is skipped.
• Filters on body.* will return null (since parsing fails gracefully).

Custom signing (beta)

For providers with a non-standard signing scheme, custom signing lets you define your own verification algorithm in a small JavaScript function. See the Custom signing page (beta) for details.