Hookbase is a webhook capture, inspection, and replay platform. Point any external service at your unique source URL and every request gets stored, making it instantly inspectable and re-fireable from your dashboard.

Get your first webhook captured in under 2 minutes.

https://hookbase.dev/hook/hk_a8f29xq7

A source is a public webhook URL that accepts any HTTP request, including GETPOSTPUTDELETEPATCH and records it.

https://hookbase.dev/hook/{token}

Every HTTP request received by a source is stored as an immutable Request record containing:

• Method— GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD, etc.
• Headers— All request headers including Content-Type, Authorization, X-Signature, etc.
• Raw body— The full unmodified request body as text
• Path— Full request path including query string
• Status— HTTP response status code returned to the sender
• Duration— Time in milliseconds to process and respond
• IP address— Source IP (respects X-Forwarded-For and Cloudflare CF-Connecting-IP headers)
• User agent— The sending application identifier
• Timestamp— Exact time the request was received (UTC)

Example captured request

A typical captured request includes the provider event type and the original JSON body exactly as it arrived. For example, a Stripe checkout webhook might look like this when viewed in Hookbase.

{
  "id": "evt_1TC9aIQSDFag5pz3YkqiPvar",
  "object": "event",
  "type": "checkout.session.completed",
  "created": 1773799905,
  "data": {
    "object": {
      "id": "cs_test_a1dWK6Mxx1rBnOAwubUKrrsW2L3TrPU40bQfllknsHzF61GRUUof8rPFeT",
      "object": "checkout.session",
      "customer": "cus_Sc8w7AuxaTS3kd",
      "currency": "gbp",
      "amount_total": 2900,
      "payment_status": "paid",
      "status": "complete",
      "mode": "subscription",
      "subscription": "sub_1TC9aGQSDFag5pz3TH9zLstW",
      "metadata": {
        "referenceId": "f138789f-4773-4f90-a15b-921cad28f92d",
        "userId": "f138789f-4773-4f90-a15b-921cad28f92d"
      }
    }
  }
}

Filtering & search

The Requests page supports powerful server-side filtering — all filters are applied in the database, not the browser:

Pinning

Sharing

Payload compare

Analytics

The analytics view aggregates request data over time — request volume, error rates, latency percentiles (p50 / p95 / p99), and status class breakdown. Switch between per-source and project-wide views. Data is sampled and cached to keep dashboards fast even at high request volumes.

Replay takes a captured request and re-fires it as a real HTTP call to any destination URL. The original method, headers, and body are preserved exactly. Replays are asynchronous — the job is queued immediately and executed in the background with automatic retries.

Job statuses

Common use cases:

• Test a new version of your API against real production traffic
• Debug a failed webhook without waiting for the external service to re-send
• Replay to a local dev server during development
• Load test with real payload shapes from production

A destination is a saved URL with optional custom headers that you can select when replaying requests instead of typing a URL each time.

https://api.myapp.com/webhooks/stripe

http://localhost:4000/webhook

https://staging.myapp.com/hooks/payments

Destinations belong to a Project. You can only replay a request to a destination in the same project, which helps prevent routing production data to an unrelated project.

Destinations can carry extra headers that get merged on top of the original request headers. This is useful for adding authentication to your destination, for example X-Internal-Secret: ....

Routing rules let you automatically forward or drop incoming webhooks based on conditions evaluated at capture time. Rules are evaluated in priority order (lowest number first) so you have full control over the pipeline.

Match conditions

matchConfig: { "header": "x-event-type", "value": "payment" }

matchConfig: { "path": "$.type", "value": "payment_intent.succeeded" }

matchConfig: { "operator": "AND", "conditions": [
  { "type": "HEADER_EQUALS",    "config": { "header": "x-source", "value": "stripe" } },
  { "type": "JSON_PATH_EQUALS", "config": { "path": "$.type",   "value": "charge.succeeded" } }
]}

Actions

actionConfig: { "targetIds": ["<target-a>", "<target-b>"] }

Any FORWARD_TO_TARGET or FAN_OUT rule can optionally include a transformConfig to reshape the JSON body before it is forwarded. The original stored payload is never modified.

{ "op": "rename", "from": "customerId", "to": "uid" }

{ "op": "drop", "field": "customer.email" }

{ "op": "set", "field": "env", "value": "production" }

Priority & ordering

Every rule has a numeric priority (default 100). Rules with a lower number run first. If a DROP rule matches, the pipeline stops — no later rules are evaluated. Multiple FORWARD and FAN_OUT rules can all fire for the same request.

Source scope

A rule can be scoped to a specific source or to the entire project (leave Source blank). Project-wide rules are evaluated alongside source-specific rules, all sorted by priority together.

Example — simple forward

{
  "name": "Route Stripe payments to staging",
  "priority": 10,
  "matchType": "JSON_PATH_EQUALS",
  "matchConfig": { "path": "$.type", "value": "payment_intent.succeeded" },
  "actionType": "FORWARD_TO_TARGET",
  "actionConfig": { "targetId": "<replay-target-id>" }
}

Example — compound match + fan-out

{
  "name": "Stripe charge events from production",
  "priority": 20,
  "matchType": "COMPOUND",
  "matchConfig": {
    "operator": "AND",
    "conditions": [
      { "type": "HEADER_EQUALS", "config": { "header": "x-source", "value": "stripe" } },
      { "type": "JSON_PATH_EQUALS", "config": { "path": "$.type", "value": "charge.succeeded" } }
    ]
  },
  "actionType": "FAN_OUT",
  "actionConfig": { "targetIds": ["<target-a>", "<target-b>"] }
}

Example — payload transform

{
  "name": "Strip PII before forwarding",
  "priority": 30,
  "matchType": "ALL",
  "actionType": "FORWARD_TO_TARGET",
  "actionConfig": { "targetId": "<replay-target-id>" },
  "transformConfig": {
    "rules": [
      { "op": "drop",   "field": "customer.email" },
      { "op": "rename", "from": "customerId", "to": "uid" },
      { "op": "set",    "field": "env", "value": "production" }
    ]
  }
}

Alerts let you get notified when something goes wrong with your webhooks. You configure channels (where to send) and rules (when to fire). Every alert dispatch is recorded as an AlertExecution for full audit history.

Channel types

{ "to": ["[email protected]", "[email protected]"] }

{ "url": "https://hooks.example.com/alert", "headers": { "Authorization": "Bearer <token>" } }

{ "integrationKey": "<routing-key>", "severity": "error" }

{ "url": "https://hooks.slack.com/services/T00/B00/xxxx" }

{ "url": "https://discord.com/api/webhooks/123/xxxx" }

Rule types

{ "endpointId": "<source-id>", "minStatus": 400 }

{ "endpointId": "<source-id>", "windowMinutes": 15 }

{ "targetUrl": "https://api.example.com" }

{ "targetId": "<target-id>", "consecutiveFailures": 3 }

Example rule

{
  "name": "Payment source errors",
  "type": "NON_SUCCESS_STATUS",
  "params": {
    "endpointId": "<your-source-id>",
    "minStatus": 400
  },
  "channelId": "<your-channel-id>"
}

The Failed Deliveries page (/dashboard/jobs) collects Replay Jobs and Forward Logs that have exhausted all automatic retry attempts. It gives you a single place to triage, retry, or permanently discard delivery failures.

What ends up here

Actions

Retry policy

Workspaces let you collaborate. Every workspace has members with one of three roles:

To invite someone, go to Workspaces → Manage → Invite member. An invitation email is sent with a link that expires in 7 days.

Owners can grant individual MEMBER-role users additional permissions beyond read-only access. Expand a member row in the Members tab to toggle permissions:

Enterprise workspaces can authenticate users through a corporate identity provider via Single Sign-On (SSO) and automate user lifecycle management through SCIM provisioning. Both are configured per-workspace from Workspaces → Manage → Enterprise.

Single Sign-On

Hookbase supports both OIDC (OpenID Connect) and SAML 2.0 identity providers — Okta, Azure AD, Google Workspace, Auth0, and any other standards-compliant IdP.

How SSO sign-in works

SP metadata for SAML

When configuring your IdP, use the following callback URL as the ACS (Assertion Consumer Service) URL:

https://<your-domain>/api/auth/sso/saml2/callback/ws-<workspace-id>

SCIM Provisioning

SCIM 2.0 lets your directory provider (Okta, Azure AD, JumpCloud, etc.) automatically create, update, and deactivate Hookbase accounts as people join or leave your organisation.

Hookbase automatically infers the JSON schema of every captured webhook payload. As your upstream service evolves its payload structure, Hookbase stores each new schema as a versioned snapshot — so you always have a complete history of how your webhook shape has changed over time.

How auto-detection works

Viewing schema history

Every schema version is visible in the dashboard under Schemas, or per-source via the Schema button in the Sources table. Each row shows the version number, a short hash, the capture date, and the contract badge.

Diffing versions

The diff view highlights exactly what changed between any two schema versions — colour-coded green for added fields, red for removed, and yellow for type changes.

Hookbase schema diff <endpoint-id> --from 1 --to 3
# Output:
#   + body.amount       (number)  — added
#   ~ body.currency     type changed: null → string
#   - metadata.legacy   removed

Pinning a contract

The contract is the schema version you consider stable. Only one version per source can be the contract at any time. Pinning a new version automatically unpins the previous one.

# Pin version 2 as the stable contract
Hookbase schema set-contract <endpoint-id> 2

Mock payload generation

Hookbase can generate a realistic mock JSON payload that matches the pinned contract schema and POST it to any URL. This is useful for:

• Testing your webhook handler locally without a real upstream service.
• Running integration tests in CI pipelines.
• Smoke-testing new deployments against the expected payload shape.

# Generate a mock payload and POST it to your local handler
Hookbase mock <endpoint-id> --forward-to http://localhost:3000/webhook

# Use in CI — exit 1 if response is not 200
Hookbase mock <endpoint-id> \
  --forward-to http://localhost:3000/webhook \
  --assert-status 200

Command reference

The Hookbase CLI gives you full terminal access to your webhook platform — tunnel public URLs to localhost, inspect and replay captured requests, manage sources, run schema contract tests in CI, and configure your workspaces without touching the dashboard.

Installation

npm install -g hookbase-cli

brew install Hookbase/tap/Hookbase

curl -sSL https://cli.hookbase.dev/install.sh | sh

Authentication

Hookbase login

Hookbase requests list --api-key whk_live_xxxxxxxxxxxxxxxx

export Hookbase_API_KEY=whk_live_xxxxxxxxxxxxxxxx

Tunnel — public URL to localhost

The tunnel command is the fastest way to expose your local webhook handler to the internet. It auto-creates a temporary source, prints the public URL, streams all incoming requests to your local server, and deletes the source on exit.

# One-command public URL for your local server
Hookbase tunnel --forward-to http://localhost:3000/webhooks
# → Public URL: https://hooks.yourdomain.com/hook/a4992507...
# Ctrl+C to stop and delete the temporary endpoint

Forwarding from an existing source

The listen command opens a persistent SSE connection and proxies every incoming request to your local server.

Hookbase listen <endpoint-id> \
  --forward-to http://localhost:3000/webhooks

Replaying requests

Replay any captured request to a new destination — useful for local debugging after a handler failure.

Hookbase replay req_01hxyz \
  --to http://localhost:3000/webhooks

Schema contracts & mock testing

Hookbase auto-detects the JSON schema from every captured payload. Use the schema and mock commands to inspect version history, diff schema changes, pin a stable contract, and drive contract tests directly from the CLI.

# In your CI pipeline:
Hookbase mock <endpoint-id> \
  --forward-to $WEBHOOK_HANDLER_URL \
  --assert-status 200

Configuration

Use Hookbase config to inspect your current settings or point the CLI at a self-hosted instance:

# View current config
Hookbase config show

# Point at a self-hosted instance
Hookbase config set-api-url https://api.yourdomain.com

Command reference — Auth & identity

Command reference — Sources

Command reference — Requests

Command reference — Replay

Command reference — Tunnel & listen

Command reference — Schema & mocks

Command reference — Projects & workspaces

Command reference — Routing rules

Command reference — Config

Global flags