Glossary
SSE vs Webhooks
Two ways a server pushes events: Server-Sent Events stream over a connection the client holds open; webhooks POST to a public URL the receiver operates. Different problems, often confused.
Server-Sent Events (SSE) keep one HTTP connection open and stream text/event-stream messages down it — the client (usually a browser, increasingly an AI agent runtime) initiates and holds the connection, and events flow only while it's connected. Webhooks are server-to-server: the provider POSTs each event to a public HTTPS URL you operate, whether or not anything is 'listening' at that moment.
The decision hinges on who can be reached. A browser tab or a process behind NAT can't expose a public URL, so it consumes SSE (or WebSockets). A backend integration that must never miss an event wants webhooks: deliveries are retried, signed, and don't depend on a connection surviving. SSE has no delivery guarantee — disconnect and you rely on Last-Event-ID resumption, if the server implements it.
They compose rather than compete: a common architecture receives webhooks server-side (durable, verified) and fans them out to connected clients over SSE or WebSockets for live UI. MCP servers use SSE-style streams for exactly this last hop.
How HookSense helps
HookSense is this composition in one tool: providers POST webhooks to your endpoint (durable, signature-verified), the dashboard streams them to you live over WebSocket, and an agent gets the same push via `wait_for_callback` over MCP — no public URL required on the agent's side.
Get a free webhook URL