A Public Event Catalog, Endpoint Lifecycle Events, and Recover-Since Replay

Three Small Gaps on the Outbound Side

None of today's changes are one big feature — they're three gaps that all showed up in the same place: the outbound webhooks you send to your own customers. An integrator asking "what events can you even send me, and what do they look like?" had no answer that didn't involve sharing dashboard access. Your own alerting had no way to hear about an endpoint being created or edited, only disabled. And recovering a customer's missed events after an outage meant hand-picking failed messages one at a time instead of saying "everything since 2:14pm."

All three shipped together because they're the same theme: giving the people on both ends of your outbound webhooks — you and your integrators — better tools for the ordinary parts of running them.

What's New

• Public Event Catalog — a read-only page at /webhook-catalog/your-org-slug listing every event type you've explicitly published, with its schema and an example payload, browsable with no login required
• Publish/unpublish per event type — a toggle right on the event type in Outbound → Webhooks; nothing is public by default, you opt each one in
• Three new operational webhook events — endpoint.created, endpoint.updated, and endpoint.deleted join the existing message.exhausted, circuit_breaker.opened/closed, and endpoint.disabled set, each toggleable independently on your alert webhook
• "Recover since" bulk replay — instead of replaying up to 100 recent failures, pick a timestamp and replay every failed, exhausted, or DLQ'd message for an endpoint from that point forward, in chronological order, capped at 500
• Recovery is now a Portal capability, not just a dashboard one — the same recover-since logic is exposed to your own customers through the embeddable Portal, so they can self-serve a recovery after their own endpoint had downtime, without filing a ticket with you

A Catalog That Costs You Nothing to Keep Accurate

The catalog is deliberately narrow: it reads directly from your event type configuration, filtered to whatever you've marked public and still enabled. There's no separate content to author and no docs page to fall out of sync with what you actually send — if the schema or example payload on an event type changes, the catalog reflects it on the next request, because it's the same record your dashboard already shows you. Un-publishing an event type is one click and it's gone from the catalog immediately.

That also means the bar for publishing something is just "is this accurate," not "do I have time to write documentation for it" — which is the reason most internal event catalogs never get built at all.

Recover-Since, Built Once, Used Twice

The old bulk replay only had one mode: replay whatever's currently failed for this endpoint, capped at 100 messages. Useful right after a short blip, useless after anything longer — if an endpoint was down for six hours, "replay the most recent 100 failures" doesn't come close to covering what was missed.

The replay service gained a second mode modeled on Svix's Recover: pass a since timestamp and it replays everything — failed, exhausted, or already dead-lettered — created at or after that point, oldest first, capped at 500 instead of 100 since it's a deliberate recovery action rather than a routine retry. An option to include unattempted messages can pull in the ones that were never even attempted — lost to a stuck queue consumer rather than a real delivery failure, which "replay the failures" would never have caught in the first place.

The reason it's one shared service instead of two near-identical implementations: it's called from both your dashboard and the embeddable Portal your customers use. Build recovery once, and both surfaces get it — including the part where your customers can trigger their own recovery after their endpoint comes back up, instead of that always being a message to your support queue.

Try It

Publish an event type from Outbound → Webhooks and open View public catalog to see it live. Toggle on endpoint.created/updated/deleted on any alert webhook to start hearing about endpoint changes. And next time an endpoint has come back from an outage, look for the recover option on that endpoint's replay action — pick a timestamp instead of picking through a list of failures one at a time.