Webhooks 2.0

Today, webhooks created by apps surface directly in the creator's Rules page with no indication of where they came from. The Fetchbase team's support ticket captured the problem exactly: a creator with 428 tags ends up with 856 system-generated webhook rules that clutter their dashboard and make their own automations impossible to manage. When apps are uninstalled, those webhooks remain — owned by an app that no longer has access to clean them up.

Giving webhooks their own dedicated page solves the pollution problem, but it also sets up everything else in this prototype. You can't add filtering, performance monitoring, or editing to something buried inside another feature's UI. A standalone page is the foundation the whole experience builds on.

Kit's current architecture requires a separate webhook per object instance — one per tag, one per form, one per sequence. That means a developer monitoring all tag changes for a creator needs 856 webhooks, not 2. This isn't just a UX annoyance; it makes real-time sync impractical at scale and forces apps to resort to polling workarounds.

The prototype models multi-event endpoints as the default: one URL, one signing secret, a selected set of events. The Stripe analysis makes the case for why this is the right data model: with single-event endpoints, developers are forced into either endpoint sprawl (separate URL per event, N signing secrets) or an over-permissioned catch-all. Multi-event lets them do what they actually want. The Stripe research also flags this as a "build it into the data model now" decision — retrofitting it later requires a breaking migration.

Most webhook UIs show a simple "last delivery: success / fail" status badge. This misses the most dangerous failure mode: sustained silent degradation. An endpoint failing 20% of deliveries looks "Active" if the last one happened to succeed — but hundreds of events have been silently dropped.

The Stripe research identifies their dual-line sparkline — total deliveries overlaid with failures — as specifically designed to make this impossible to miss across the whole list without clicking in. The visual gap between the two lines is the error signal. The prototype adopts the same pattern. Hovering a sparkline shows the delivery stats for that webhook.

The prototype offers two payload modes. Snapshot embeds the full object state in the payload — self-contained, no follow-up API call required, the right default for creators, Zapier automations, and simple scripts. Thin sends only event metadata and a resource ID; the developer fetches current state from the API at processing time.

The distinction matters for production integrations. Thin payloads are naturally idempotent — fetching the API always returns current state, so retried events don't cause stale data problems. They're also smaller, which matters at high volume. The Stripe analysis recommends offering both and defaulting to snapshot for its lower barrier to entry, with thin as an explicit developer opt-in. The PRD includes payload style as a first-class configuration option in the creation flow.

The current Kit experience gives developers no visibility into whether their webhooks are working. There's no delivery log, no error rate, no performance history — just a status badge that says active or inactive. Developers find out webhooks are failing when their integration breaks, not before.

The Stripe research breaks down exactly what each chart type reveals: the event deliveries chart (total vs failed) shows whether failures are isolated incidents or sustained degradation. The response time chart (min/avg/max) surfaces whether a receiving server is slowing down before it starts returning errors — a leading indicator of an impending failure. The three-line response time view is particularly useful for distinguishing a consistently slow handler from one that's usually fast but occasionally times out. The prototype implements both charts with a 7-day window.

HMAC signing secrets are the primary security mechanism for webhooks — they let developers verify that deliveries genuinely come from Kit and haven't been tampered with. The PRD identifies signatures as a significant piece of work (ECO-2860) and a reliability priority.

Secret rotation is where most webhook implementations fall down. If rolling the secret immediately invalidates the old one, a developer must coordinate their server deployment exactly with the roll — any delay drops deliveries or causes auth failures. Stripe's approach, adopted in this prototype, is a 24-hour overlap window where Kit accepts signatures from both the old and new secrets simultaneously. This allows zero-downtime rotation: roll the secret, update the environment variable, deploy at your own pace, and the old secret stays valid until the window closes. The roll endpoint (POST /v4/webhooks/{id}/roll_secret) is also available via the API so rotation can be automated.

The PRD identifies documentation as one of the most actionable improvements: Kit's current webhook docs are sparse, hard to find, show everything as "required" even when it isn't, have no payload examples, and don't explain what actually triggers each event. Developers are expected to piece together integrations from incomplete reference material.

The prototype embeds a full documentation experience for convenience — so reviewers can see the content in context — but the real home for this is developers.kit.com, not in-app. The prototype's docs are modelled on the existing developer docs site style, with several patterns borrowed from Stripe. Per-page code samples in four languages update as you navigate. The quickstart leads with the return-2xx-then-process pattern, which the Stripe analysis identifies as "the single most common developer mistake" — doing expensive work synchronously causes timeout → retry → timeout loops. The testing guide, idempotency guidance, and CSRF exemption instructions are drawn from patterns Stripe documents because developers consistently get tripped up on them.