Webhooks vs WebSockets: Which Channel Fits Agent Email

2026-11-06

The usual advice, use WebSockets for real time and webhooks for everything else, skips the failure that matters most for agent email: a notification arrives, the agent sends a reply, and the process crashes before recording success. Changing the transport won't prevent the next delivery from triggering another reply. The useful comparison is where durable state, recovery cursors, and side-effect protection live when the transport fails.

For developers wiring email into Claude Code, Cursor, Codex, MCP, or a REST API, that distinction changes the build. A live interface needs a connection manager. An autonomous email worker needs durable work records and a safe way to recover uncertain sends.

Table of Contents

• Webhooks and WebSockets at a Glance
  • Transport behavior isn't product quality
• How Each Connection Model Moves an Event
  • The webhook path
  • The WebSocket path
• Latency and Overhead in Practice
  • Read the conditions with the figures
  • Measure the agent's actual path
• Retries, Duplicates and Replays
  • Accept work before acknowledging it
  • A valid signature doesn't establish freshness
  • A connected socket isn't a durable log
• Operating Cost at Scale
  • Budget for sessions, not just messages
  • Webhooks replace session costs with delivery costs
• Which Channel Fits Each Agent Job
  • Build the durable worker before the live interface
  • A hybrid email workflow
  • Test the failure boundary

Webhooks and WebSockets at a Glance

A webhook is an HTTP POST that a sender makes to an endpoint after an event happens; a WebSocket is a persistent TCP connection, typically opened through an HTTP upgrade, that either side can write to during the session.

Webhooks and WebSockets compared

The latency figures describe published comparison scenarios, not transport guarantees: Robotomail's webhook and WebSocket comparison places webhook delivery in the low hundreds of milliseconds and WebSocket chat-style updates under about 50 milliseconds. Neither figure says how long an email agent takes to read a thread, generate an answer, or complete a send.

Transport behavior isn't product quality

A webhook receiver can acknowledge promptly and then leave work stuck in a queue. A WebSocket server can push immediately while its client discards messages during a reconnect. Delivery speed and completed work are different measurements.

Webhook also has an overloaded meaning. A product's webhook feature might include endpoint management, signatures, logs, and replay tools, but the transport itself is an HTTP callback. This comparison uses that transport meaning.

For backend integration patterns, Wonderment Apps' resources on webhooks for scalable applications provide additional context. For an email-specific channel inventory, the real-time events overview helps separate external notifications from a continuously connected consumer.

First check: Does an event cross between independently operated systems, or does an online client need a continuous session with messages moving both ways?

That question usually narrows the choice before latency tuning starts.

How Each Connection Model Moves an Event

A webhook sender initiates a delivery because something changed. The receiver doesn't need to maintain a session with that sender between notifications, but it does need a reachable endpoint and an acknowledgement policy.

The webhook path

1. An event occurs on the sender.
2. The sender builds an HTTP POST containing the event body.
3. The receiver returns a successful HTTP status to acknowledge acceptance.
4. If no successful acknowledgement arrives, the sender retries according to its delivery policy.

The distinction between accepted and completed matters. An acknowledgement should mean that the receiver has durably accepted responsibility for the work, not that an agent has already generated and sent an answer.

The callback sequence has a short request lifecycle, even when the downstream job takes longer.

The receiving code is an idempotent HTTP handler backed by durable storage. It authenticates the request, records accepted work, and leaves thread retrieval and reply generation to a worker.

The WebSocket path

The WebSocket protocol guide describes the upgrade, frame exchange, and control-frame lifecycle:

1. The client sends an HTTP request with an Upgrade header.
2. The server accepts the upgrade with 101 Switching Protocols.
3. Both endpoints exchange frames over the established TCP connection.
4. Ping (0x9) and Pong (0xA) check connection health, and a peer answering a Ping must echo its payload as soon as possible.
5. A Close (0x8) frame and its reply perform the shutdown handshake before the TCP connection closes.

Here, receiving code becomes a connection manager. It owns authentication, subscriptions, reconnect scheduling, shutdown handling, and the distinction between connected and caught up. A successful handshake only establishes the channel; it doesn't prove that the application has recovered missed work.

SupportGPT's real-time chat protocols explained offers useful context for session-oriented interfaces. The same lifecycle questions apply to an agent console, although chat display and autonomous email processing shouldn't share the same assumptions about recoverability.

For the surrounding worker architecture, building an email pipeline for AI agents connects notifications to thread processing. Keep the transport adapter separate from the business worker so a callback, scheduled read, or resumed stream can submit work through the same durable entry point.

Pick the model whose failure handling the receiving application is ready to implement. A short HTTP handler isn't complete without durable acceptance, and a socket isn't complete without reconnect and shutdown behavior.

Latency and Overhead in Practice

The latency advantage of an established socket comes from avoiding a new application-level HTTP callback for each update. That advantage matters when an operator waits for changing inbox state or a chat interface exchanges frequent messages. It matters less when an agent's next operation is an external API request or model invocation.

Read the conditions with the figures

Indicative latency and overhead figures

The polling and push figures come from Render's WebSocket implementation guidance, which describes moving from roughly 200 to 500 ms polling intervals to approximately 1 to 10 ms direct push. Those are implementation examples, not universal bounds: an application chooses its polling schedule.

An independent comparison in a publicly filed technical document reports approximately 2 to 6 bytes of WebSocket framing per message, and about 600 bytes per second versus 60,000 bytes per second of overhead at 100 messages per second. Frame direction, masking, payload length, and HTTP connection reuse affect comparisons, so these figures shouldn't become a capacity forecast.

Measure the agent's actual path

Instrument separate timestamps for event creation, receiver acceptance, worker start, authoritative-state retrieval, and completed action. Otherwise, a queue backlog can look like transport latency, and slow generation can conceal a notification improvement.

Test the reconnect path as well as the connected path. A socket benchmark that excludes disconnected clients measures only the easiest operating condition.

Optimize transport latency when a person or interactive client waits on each event. Optimize durable processing when software must finish the job after that client disappears.

At low event frequency, framing savings rarely justify a connection fleet by themselves. At sustained message rates, measure bandwidth alongside connection memory, worker throughput, and recovery time.

Retries, Duplicates and Replays

Duplicates are normal. A sender can retry after a timeout even though the receiver already accepted the event. If the original acknowledgement disappeared, the sender has no evidence that delivery succeeded.

Svix's webhook reliability guide defines the useful reliability target as eventual delivery, the proportion of events receiving a successful 2xx response within the retry window, rather than first-request success. Bounded retries with exponential backoff give a recovering receiver another chance; dead-letter handling or an operator recovery path handles exhausted attempts.

Accept work before acknowledging it

A receiver should make the following sequence explicit:

1. Verify the signature before parsing. For an HMAC-SHA256 scheme, authenticate the raw request body using the endpoint secret and the sender's exact signed-content format, including timestamp or identifier fields where required.
2. Check the event ID against durable storage and return the stored acknowledgement outcome for an already accepted event.
3. Record the event ID and pending work atomically. A database transaction with a uniqueness constraint and a work or outbox record prevents concurrent deliveries from scheduling duplicate jobs.
4. Return 2xx only after that durable write succeeds.
5. Route exhausted processing failures to a dead-letter or replay path with enough context for an operator to diagnose them.

The work record should represent acceptance, not pretend that the outbound email is already complete. Track processing and send outcomes separately, including an uncertain state when an external request times out.

A database transaction can protect local records, but it can't automatically commit an external email send. If a worker sends successfully and crashes before recording success, blindly retrying the send can still produce duplicate mail. Use a stable action identifier and downstream idempotency where supported; otherwise, reconcile the uncertain outcome before attempting another send.

A valid signature doesn't establish freshness

An attacker who captures an authenticated delivery may resend it without changing its signature. The OWASP Webhook Security Cheat Sheet recommends signing a Unix timestamp with the payload, generating a fresh timestamp and signature on each retry, and rejecting authenticated timestamps outside a small clock-skew window; it also notes Stripe libraries' default five-minute tolerance.

Synchronize the receiver's clock with NTP. Validate freshness and deduplicate event IDs as separate checks: a legitimate retry can have a fresh signature while referring to work that was already accepted.

The same distinction applies outside email. PlatformDTC's discussion of coupon API endpoints provides an adjacent API-design context: authenticating a caller and preventing a repeated business action solve different problems. An email reply needs an action-level guard just as another state-changing operation does.

A connected socket isn't a durable log

CloudTalk's webhook delivery guidance highlights the broader at-least-once problem: neither callbacks nor persistent connections provide exactly-once business effects by themselves. For WebSockets, add application acknowledgements, sequence numbers, and a catch-up operation that accepts the client's last durably processed position.

Advance that position only after the corresponding work is safely recorded. Advancing it on receipt can skip work after a crash; never advancing it forces unnecessary replay.

The receiver must produce the same business result when the same event arrives again, even when another worker is already processing it.

That requirement belongs in storage constraints and worker transitions, not in a prompt asking the agent to remember previous actions.

Operating Cost at Scale

Each WebSocket server holds connection state, a cost a webhook receiver doesn't retain between events. Scaling therefore involves connection ownership as well as request routing.

The WebSockets at scale guide describes Layer 4 or Layer 7 load balancing with session affinity, or externalized state that lets reconnecting clients land on another backend. A pub/sub backplane such as Redis, Kafka, or NATS routes messages to whichever server owns the destination connection.

Budget for sessions, not just messages

The costs of a socket fleet need explicit controls:

• Handshake authentication: Validate credentials before allocating a subscribed session, and define what happens when credentials expire.
• Message authorization: Check mailbox and operation permissions when processing messages rather than treating the handshake as permanent authorization.
• Rate limiting: Apply connection-level limits alongside mailbox or account budgets so opening another connection doesn't bypass controls.
• Heartbeat timeouts: Detect unresponsive peers and release resources rather than retaining dead sessions.
• Backpressure: Bound each client's outgoing buffer; disconnect or require catch-up when a slow reader exceeds that bound.
• Memory and file descriptors: Capacity-plan open sessions and buffered data, not merely messages processed.

Externalized subscription metadata doesn't move an existing TCP connection to another process. A backend restart still disconnects its clients; shared state and replay make that interruption recoverable.

Webhooks replace session costs with delivery costs

Webhook receivers need queue-depth monitoring, endpoint availability, timeout tuning, and signature verification on each request. After an outage, retries can arrive alongside new traffic, so receiver concurrency and worker concurrency should have separate limits.

Consider an operator dashboard with many idle browser clients while backend workers process mail only when messages arrive. The dashboard sockets consume memory and heartbeat traffic throughout the session. Webhook receivers hold no event-specific connection between deliveries, but must absorb recovery traffic when their endpoint returns after an outage.

Sticky sessions are a practical starting point at moderate scale. Introduce shared subscription and recovery state when losing a backend would otherwise lose session context that matters. Neither option replaces a durable event position, and neither makes a retry backlog disappear.

Which Channel Fits Each Agent Job

Channel by agent job

The communication pattern should follow the job rather than the tool hosting the agent. Claude Code, Cursor, and Codex can invoke tools, but the surrounding application still needs to decide who owns the long-running listener and who recovers unfinished work.

Molted gives each agent its own mailbox, for agents what Gmail is for humans. It isn't an API wrapper or a layer on top of Resend, Postmark, or SES, and customers need no separate email provider account. New mailboxes run autonomously, with approvals as an optional setting; agents receive mail through inbox reads, webhooks, a live event stream, or the molted listen CLI command. Deliveries, bounces, and replies arrive through an open stream or signed webhooks, while that CLI listener holds a Server-Sent Events connection, filters event types, and pipes each event to a handler as a line of JSON.

Build the durable worker before the live interface

1. Use webhooks for events a separate system must act on. Store the event ID and verify the signature at the receiving boundary. Keep agent execution outside the request handler so a slow generation doesn't extend the delivery acknowledgement.
2. Add a WebSocket or live stream only when a client needs continuously updated state, and retain a durable cursor so the application can fetch missed events after reconnecting.
3. Treat agent notifications as wake-up signals. Fetch the authoritative thread or event state before deciding what to do, then process through the durable worker.
4. Keep duplicate protection outside conversational logic. A repeated notification must encounter a storage-level guard before it can schedule another outbound message.

For an agent connected through MCP, the tool invocation is an execution interface, not a substitute for a work ledger. The same applies to a CLI process: terminal output isn't durable acceptance unless another component persists it.

A hybrid email workflow

Consider a support agent waiting for a customer's reply. A webhook wakes the handler, which verifies the request and records pending work. A worker then reads the authoritative thread and checks whether the agent still owns the conversation.

The worker derives a stable reply-action key from the mailbox, inbound message, and intended operation. A uniqueness constraint prevents another notification or concurrent worker from creating the same reply action. Only the worker holding that action proceeds to generation and the send decision.

Before sending, the worker checks the current thread again if generation may have overlapped a human handoff or another reply. It records the send request and outcome, leaving uncertain results for reconciliation instead of blindly resending. The guide to how AI agents handle inbound replies gives further context for connecting thread state to agent decisions.

An operator dashboard can subscribe independently to show accepted work, pending decisions, and completed actions. Closing that browser tab must not cancel the worker or erase its action record.

Test the failure boundary

A production check should deliberately interrupt the workflow:

• Replay an accepted event: Confirm that no additional reply action appears.
• Crash after durable acceptance: Restart the worker and confirm that pending work resumes.
• Interrupt an outbound request: Confirm that the worker records uncertainty instead of assuming failure.
• Disconnect the live client: Confirm that reconnecting restores current state without starting duplicate work.

These tests expose the difference between receiving a message and safely completing a job. They also make transport changes less risky because the same worker protections remain in place.

Webhooks suit intermittently available receivers when the retry window and catch-up path cover their downtime. Streams suit processes that stay connected and need current state. In a webhooks vs WebSockets decision for agent email, the durable worker should remain correct when either channel disappears.

Molted Email gives agents their own mailboxes with signed webhooks, live events, and MCP, CLI, or REST access, so notification handling can stay separate from agent execution. Start free at molted.email (free for people, paid plans from $19 a month).