Provider verifiers

Secret, PublicKey, and Keyset speak Standard Webhooks. For the top non-Standard-Webhooks senders, @postel/core ships ready-made verifiers instead of asking you to hand-write one:

import { Postel, Stripe, GitHub, Shopify, Twilio, Slack } from "@postel/core";
import { config } from "./config.js";

export const postel = Postel({
  inbound: {
    stripe: { verify: Stripe(config.stripeWebhookSecret) },
    github: { verify: GitHub(config.githubWebhookSecret) },
    shopify: { verify: Shopify(config.shopifyWebhookSecret) },
    twilioSms: {
      verify: Twilio(config.twilioAuthToken, "https://api.example.com/webhooks/twilio/sms"),
    },
    slack: { verify: Slack(config.slackSigningSecret) },
  },
});

All five are ordinary Verifiers — they compose in arrays/maps, report matchedVerifierIndex, and throw the same SignatureInvalid/MalformedHeader/TimestampTooOld errors as the Standard Webhooks verifiers. One important difference: the secret you pass to any of them is used as literal UTF-8 key material, exactly as that provider issues it (a Stripe secret keeps its whsec_ prefix as part of the key) — it is not run through the whsec_-strip-then-base64-decode convention Secret/PublicKey use for Standard Webhooks secrets. Twilio's url must be the exact webhook endpoint URL registered with Twilio (scheme, host, path, and query string) — Twilio signs over that URL, so a reverse proxy that rewrites what your app sees will break verification, the same caveat Twilio's own SDKs carry.

Each provider has its own page with the full recipe — the config one-liner, a gated route, the scheme's details, its gotchas, and how to test locally:

What's next

• Custom verifiers — write one for any other sender.
• Verify a signed request — the base recipe these plug into.
• Key rotation — composing old + new keys during a window.