Why use WebSockets?
| Feature | Webhook | WebSocket |
|---|---|---|
| Setup | Requires public URL + ngrok | No external tools needed |
| Connection | HTTP request per event | Persistent connection |
| Initiation | OpenMail connects to you | You connect to OpenMail |
| Firewall | Must expose port | Outbound only |
| Latency | HTTP round-trip | Instant streaming |
Connecting
Authenticate with your API key via theAuthorization header or token query parameter.
?token= query parameter is useful for browser clients and CLI tools that can’t set custom headers on WebSocket connections.
Delivery semantics
When a customer has both an active WebSocket connection and a webhook URL configured, OpenMail prefers the WebSocket. If the WebSocket is down, events fall back to the webhook with the same retry policy.| Scenario | Delivery method |
|---|---|
| WebSocket connected + subscribed | WebSocket (instant) |
| WebSocket disconnected, webhook URL set | Webhook (with retries) |
| Neither | Event stored, marked as failed |
Comparison with webhooks
Use WebSockets when:- Your agent runs locally or behind a firewall
- You want instant delivery with no round-trip latency
- You don’t want to manage a public HTTPS endpoint
- Your server is already publicly accessible
- You need guaranteed delivery with automatic retries
- You prefer stateless, request-based integration