When to use SSE vs. webhooks
| SSE | Webhooks | |
|---|---|---|
| Direction | Server pushes to agent over an open connection | Server POSTs to agent’s URL |
| Agent reachability | Agent makes the outbound connection | Agent must have a publicly reachable URL |
| Local / sandboxed agents | Works | Painful — need ngrok or similar |
| Multiple agents at once | Each gets its own channel | N webhooks per N agents |
| Delivery guarantees | Best-effort with replay buffer | At-least-once with retries |
Opening a connection
Requires a session token (sess_*):
-N disables curl’s buffering so events surface in real time.
Event types
Reconnect with Last-Event-ID
If your connection drops (network blip, client restart), Sly buffers the last 100 events (or 5 minutes, whichever is shorter). Reconnect with the last event ID you saw:Connection limits
- Heartbeat: every 30 seconds. Missing three in a row → connection closed.
- Max duration: 24 hours. At ~23:55 Sly sends a
reconnect_requiredevent. Open a new connection before the old one closes. - Session scope: one connection per
sess_*token. Opening a second closes the first.
Client patterns
Node.js (EventSource)
Python (httpx + SSE)
SDK shortcut
Liveness
The server tracks which agents are currently connected. You can query:active even when disconnected. It just won’t receive push events until it reconnects.
Endpoints
| Endpoint | Auth | Purpose |
|---|---|---|
GET /v1/agents/:id/connect | sess_* | Open SSE channel |
GET /v1/agents/:id/liveness | API key | Check connection status |
GET /v1/agents?connected=true | API key | Filter for connected agents |
