API Design
Webhook subscriptions accumulate over months and years until customers cannot remember what each one does. The fix is metadata fields that are cheap to add and disproportionately load-bearing for self-service: name, description, owner, contact, and a few others worth specifying upfront.
API Design
Every webhook product accepts a customer-supplied URL and makes HTTP requests to it from infrastructure the customer does not control. The default behavior is server-side request forgery as a product feature. Recipient allowlisting is the discipline that closes the gap.
API Design
Single-event-per-delivery is the right default for webhooks and most B2B SaaS providers ship nothing else. There are specific scenarios where batching produces large operational wins, and the boundaries between when batching helps and when it hurts are worth being explicit about.
API Design
Most webhook APIs let customers subscribe by event type and then ship every event matching the type. For high-volume integrations this is wasteful on both sides. Server-side filtering lets customers narrow further without writing infrastructure to discard most of what they receive.
API Design
Rate limits have two implementations that look identical in the documentation and behave very differently in practice. The fixed-window reset is cheap to implement and produces customer-visible cliff edges; the sliding-window reset is more expensive and produces smoother experience.
API Design
Most webhook products treat suspension as a single state, but the cause and intent behind a suspension changes what the customer should be able to do about it. The three-mode distinction prevents customer support tickets and audit confusion.
API Design
Customers accumulate webhook subscriptions over time, and at some point have more than they can mentally track. Tags are the smallest mechanism that lets customers organize their integrations, and most webhook products implement them wrong.
API Design
Customers regularly need to stop webhook delivery temporarily without losing events: deploys, planned maintenance, receiver upgrades. The pause-and-resume primitive is one of the smallest, highest-leverage features in a webhook product, and most providers ship it wrong.
API Design
Webhook providers cannot guarantee exactly-once delivery, so they push idempotency onto the receiver. The pattern is well-known to providers and consistently underdocumented for receivers. What receivers actually need to do, and the failure modes when they skip it.
API Design
Webhook deliveries fail constantly. Most failures are transient. A small fraction become persistent and the customer's integration is silently broken. The escalation question is when to interrupt with a notification, through which channel, and what the contract is for resumption.
API Design
Customer integration testing benefits from a reset operation that returns the sandbox to a known state. The endpoint shape, the rate limiting, the data isolation, the audit trail, and the patterns that turn a useful feature into a support-ticket-reducing one.
Engineering
Webhooks fail. The receiving server is down, the network hiccups, the endpoint returns a 500. This is not exceptional — it is expected. Any webhook system that does not handle failed deliveries is a w