Webhooks have quietly become the backbone of modern SaaS integrations — Stripe, GitHub, Shopify, Slack… almost every product relies on them.
On the surface, they’re just POST requests. But at scale, teams end up reinventing a lot of the same infrastructure:
- Retry queues and exponential backoff
- Dead-letter queues for failed events
- Signature validation and replay protection
- Monitoring and observability
- Customer support when “the webhook didn’t fire”
This got me thinking: are we overdue for Webhook-as-a-Service (WaaS) to be treated as a first-class primitive, the way cloud providers gave us databases, queues, and object storage?
I wrote up a guide exploring what WaaS is, how it works, and why teams are increasingly adopting it.
Curious:
1. Has your team built webhook infra in-house?
2. Do you see WaaS becoming as common as using S3 or RDS instead of rolling your own?
3. Or is webhook delivery “too small” a problem to deserve its own category?
Tanjim|6 months ago
On the surface, they’re just POST requests. But at scale, teams end up reinventing a lot of the same infrastructure:
- Retry queues and exponential backoff - Dead-letter queues for failed events - Signature validation and replay protection - Monitoring and observability - Customer support when “the webhook didn’t fire”
This got me thinking: are we overdue for Webhook-as-a-Service (WaaS) to be treated as a first-class primitive, the way cloud providers gave us databases, queues, and object storage?
I wrote up a guide exploring what WaaS is, how it works, and why teams are increasingly adopting it.
Curious: 1. Has your team built webhook infra in-house? 2. Do you see WaaS becoming as common as using S3 or RDS instead of rolling your own? 3. Or is webhook delivery “too small” a problem to deserve its own category?
Would love to hear HN’s take.