Verify Stripe, GitHub, Clerk, Slack, and Resend before they reach your agent

A forged webhook reaching a classical API endpoint is annoying — you log the bad request, maybe alert on it, and move on. A forged webhook reaching an AI agent is expensive. The agent will happily spend LLM tokens, make tool calls, and possibly take an action in the real world — exactly like it would for a real event.

That changes the cost of getting signature verification wrong. Every event reaching your agent should be signed, verified, and marked as such before the agent ever sees it.

Hooksbase ships this as provider packs on Starter+. Configure a webhook for a supported provider, authenticate the HTTP ingest request with the Hooksbase bearer secret, and provider signature verification happens before persistence. When a provider dashboard cannot attach the bearer header, put a small verification forwarder in front of Hooksbase.

Supported providers

• Stripe — signature verification against your webhook secret. Extracts provider.sourceId, provider.eventType.
• GitHub — X-Hub-Signature-256 verification. Extracts the event type from X-GitHub-Event and delivery ID from X-GitHub-Delivery.
• Clerk — Svix-compatible signature scheme.
• Slack — signing secret verification plus inline handling of the url_verification challenge (no delivery is persisted for challenges; the challenge string is echoed back directly).
• Resend — signature verification for Resend webhook secrets.

Each provider's verification runs after Hooksbase ingest auth and before the delivery is persisted. Fail verification → 401 before any delivery is stored. Pass verification → provider.verified = true is stamped on the delivery record.

Provider metadata as routable fields

Beyond provider.verified, Hooksbase extracts and stores:

• provider.name — "stripe" | "github" | "clerk" | "slack" | "resend"
• provider.sourceId — the provider's own event ID (Stripe's evt_*, GitHub's delivery UUID, etc.)
• provider.eventType — the event type the provider classified it as

These aren't just tags — they're routable. Routing rules can match on provider.eventType eq "invoice.payment_succeeded" or provider.verified eq true. Delivery search can filter on them. Invalid provider signatures are rejected before persistence, so failed verifications do not become "unverified" deliveries in the DLQ.

Example: one project, multiple agents

Say you have two agents: a billing-automation agent and a security-alert agent.

Webhook: main-inbound (stripe provider pack enabled)
Destinations:
  - billing-agent (SQS queue)
  - security-agent (HTTP webhook to agent endpoint)

Routing rules (priority order):
  1. provider.name eq "stripe" AND provider.eventType starts_with "invoice."
     → billing-agent
  2. provider.name eq "stripe" AND provider.eventType eq "radar.early_fraud_warning"
     → security-agent
  3. default → billing-agent (catch-all)

Stripe sends a signed webhook to a pass-through forwarder, or a custom producer calls Hooksbase directly with bearer ingest auth. Hooksbase verifies the provider signature. The provider pack extracts eventType = "invoice.payment_succeeded". Routing rule #1 matches. The event hits the billing agent's SQS queue. A fraud-warning event in the same webhook endpoint would take rule #2.

No provider verification code in the agent. The agent sees a verified, typed, routable event.

What your agent receives

Provider metadata is persisted on the delivery and available to routing, search, and replay metadata. It is not automatically injected into the outbound HTTP body, and payload transforms currently see the payload, headers, and content type rather than the provider metadata object. Your agent receives the original provider payload unless you configure a payload transform over that payload, and it should verify the Hooksbase outbound signature headers (webhook-id, webhook-timestamp, webhook-signature) to trust that the event came through the relay.

What this replaces

Without provider packs, every agent team writes:

1. A verifier for each provider (Stripe uses HMAC-SHA256 with t=...,v1=... concatenated, GitHub uses hex-encoded HMAC, Slack uses a versioned signing scheme, etc.)
2. A router that branches on some provider-specific field
3. An error path for bad signatures that doesn't accidentally fire the agent anyway
4. Logging and observability around which events are arriving verified vs unverified

Four things that are easy to get 90% right and surprisingly easy to get 10% wrong. Provider packs handle all of it, on Starter+.