Add reliable outbound webhooks to your SaaS
Your customers want webhooks. You don't want to build the retry loop, the signing infrastructure, the replay UI, or the per-customer log viewer. Ship the feature without writing the platform.
The problem
Webhooks are a table-stakes feature in B2B SaaS. The minute a customer asks, 'can you POST events to our endpoint?', your roadmap acquires a webhook commitment. The first version is fast: a worker that posts JSON to a URL.
What follows is the long tail of webhook engineering: retries with backoff (not too many, not too few), classifying transient vs permanent failures, HMAC signatures (timing-safe compare, secret rotation, replay protection), a dead-letter queue when retries exhaust, a log UI the customer can self-serve, replay tools when the customer fixes their endpoint, audit trail for compliance reviews.
Most teams build a partial version and ship it. Then they spend the next two years answering customer tickets about deliveries that 'should have happened but didn't.'
How Pushrail solves it
Pushrail's webhook adapter is what you'd build if you had six months of focused engineering: HMAC-signed POSTs with replay-attack protection, exponential backoff with jitter, transient vs permanent classification baked in, per-attempt audit trail, replay primitive, customer-visible delivery log.
Your service emits one event via Pushrail's ingest API. Pushrail handles the rest: signing, retries, DLQ, observability. Your customers configure their endpoint URL via the dashboard (or the embedded portal). When something goes wrong, they see it in their log without filing a ticket.
Webhooks become a feature you shipped in a week instead of a feature you're still maintaining in two years.
What you ship to your customers
- Outbound HMAC-signed webhook delivery with industry-standard verification primitives.
- Retries with exponential backoff and jitter, with transient-versus-permanent failure classification.
- A dead-letter queue for events that exhausted retries, with one-click replay.
- Customer-facing delivery log scoped to the signed-in customer.
- Secret rotation that drains in-flight deliveries before revoking the old secret.
What this replaces
- Six months of internal infrastructure engineering on a feature outside your core product.
- An on-call rotation for 'a customer says deliveries are failing' tickets.
- A growing pile of credentials in your secrets store that nobody wants to own.
- The eventual rewrite when v1 doesn't scale to your tenth high-volume customer.
Concrete walkthrough
- 1. Add Pushrail's ingest call to your service. Send one canonical event per business event.
- 2. Expose a 'Webhooks' settings tab in your dashboard (or drop in the embedded portal).
- 3. Your customer pastes their endpoint URL and gets a signing secret to verify with.
- 4. Pushrail starts delivering. Your customer sees each attempt in their log; failed deliveries retry automatically and surface in their DLQ view.
- 5. When the customer's endpoint goes down for maintenance, deliveries retry, queue, and resume when it's back. The customer never files a ticket.
Related use cases
Frequently asked questions
Do I have to build the webhook retry and signing logic myself?
No. Your service emits one canonical event via Pushrail's ingest API, and Pushrail handles HMAC-signed POSTs with replay-attack protection, exponential backoff with jitter, transient vs permanent failure classification, the dead-letter queue, and the delivery log.
Can customers configure their own webhook endpoint?
Yes. Customers register their endpoint URL through your dashboard or the embedded portal, get a signing secret to verify with, and see every delivery attempt in their own log without filing a ticket.
What happens when a customer's endpoint goes down?
Deliveries retry with exponential backoff and jitter, queue while the endpoint is unavailable, and resume when it returns. Anything that exhausts retries lands in the per-destination DLQ with one-click replay.
How is secret rotation handled?
Customers rotate the signing secret from the dashboard. Old secrets keep signing in-flight deliveries until they drain, then are revoked, so no delivery is dropped during rotation.
Add reliable outbound webhooks to your SaaS
Sandbox is open. No credit card.