Hooksbase

Glossary · Product

Provider pack

Preconfigured inbound verification for a known provider — Stripe, GitHub, Clerk, Slack, or Resend.

Product

What is a provider pack?

A provider pack is preconfigured inbound verification for a known provider. Hooksbase ships provider packs for Stripe, GitHub, Clerk, Slack, and Resend — five providers whose webhook signatures are validated at the Hooksbase edge before the payload reaches your endpoint.

HTTP ingest still requires the Hooksbase ingest secret first. In practice, the provider request must include Authorization: Bearer <ingest secret>, or it must pass through a thin forwarder that preserves the raw body and provider signature headers while adding the Hooksbase bearer token.

What a provider pack does

When you configure a webhook with provider: stripe (or github, clerk, slack, resend), Hooksbase:

  1. Validates the signature using the provider's specific scheme (Stripe's t=...,v1=..., GitHub's X-Hub-Signature-256, Standard Webhooks for Clerk and Resend, Slack's v0: HMAC)
  2. Rejects forged or stale events before persistence, so quotas and downstream resources aren't burned on bad input
  3. Extracts provider metadata into queryable fields: provider.name, provider.sourceId, provider.eventType, provider.verified
  4. Handles provider-specific quirks — e.g. Slack's URL verification challenge is answered automatically

Why this matters

Without a provider pack, you'd write the verification code yourself for every provider — roughly 50 lines per provider, plus the secret rotation, plus the signature-update story when the provider changes their scheme. With a provider pack, that is all handled at the Hooksbase edge.

Providers outside the pack list (Shopify, Twilio, Notion, Plaid, Jira, Polar, etc.) can still flow through Hooksbase reliably, but Hooksbase does not verify their native signatures and outbound HTTP dispatch does not forward the original provider signature headers. If you need cryptographic verification for those providers, verify them in a small pre-ingest forwarder, then post the verified payload to Hooksbase with the bearer ingest secret. The other reliability primitives (retries, replay, DLQ, delivery history) apply after the event is accepted.

For the practical setup: Verify provider webhooks.

Frequently asked questions

Which providers does Hooksbase pre-verify?

Five: Stripe, GitHub, Clerk, Slack and Resend. Each pack validates that provider's own signature scheme, rejects forged or stale events before persistence, extracts provider metadata into queryable fields, and handles provider-specific quirks such as Slack's URL verification challenge.

What happens with providers outside the pack list?

They still flow through Hooksbase reliably, but their native signatures are not verified and outbound dispatch does not forward the original provider signature headers. If you need cryptographic verification for those, verify in a small pre-ingest forwarder and then post the verified payload with the bearer ingest secret.

What is Hooksbase?

Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.

Related terms

Back to glossary