Why a Live Chat Widget Needs a Webhook Test Button
Production webhooks fire and forget — Chat ships a separate, SSRF-guarded test endpoint specifically so you can verify your endpoint works before depending on it.
Webhooks failing silently is one of the most common, least visible reliability problems in integration-heavy software. Your endpoint changes, a certificate expires, a firewall rule shifts — and the sending system has no reason to tell you, because from its side, it fired the webhook and moved on. Chat's webhook system has this exact gap on its production path, and rather than pretend otherwise, it ships a dedicated test endpoint to close it.
The production path is fire-and-forget
Chat's production webhook dispatch (fireWebhook in the realtime library) does what production webhook dispatch generally does: it sends the payload and doesn't wait around to surface failure back to you. That's a reasonable design for the hot path — a live conversation shouldn't stall because a webhook receiver is slow or down — but it means a silently broken webhook can sit broken indefinitely with nothing in your inbox to tell you.
A separate, dedicated test route
The fix isn't retrofitting the production path with failure reporting that would slow it down. It's a distinct endpoint — /api/chat/webhooks/test — that you trigger deliberately, whose entire job is to tell you, synchronously, whether your endpoint actually works. It's a different code path from the one your live conversations depend on, built specifically for verification rather than delivery.
Guarded the same way the real thing is
The test endpoint uses safeFetch with SSRF protection (SsrfBlockedError from the platform's shared security package) — the identical guard the production dispatch path uses. That matters because a webhook test endpoint that accepts an arbitrary URL and fetches it is a textbook server-side request forgery vector if it isn't guarded; Chat's test route doesn't get a pass on that just because it's "only a test."
What this buys you
Before you depend on a webhook integration for anything real — notifying a Slack channel, syncing to an external system, triggering a downstream workflow — you can confirm your receiving endpoint is actually reachable and responding correctly, on demand, without waiting for a live conversation to accidentally reveal a problem. It's a small feature, but it's the difference between finding out your integration is broken from a customer complaint weeks later, and finding out the moment you set it up.