Real-time

SSE, with polling as the fallback

The inbox updates live over Server-Sent Events when your deployment has realtime enabled, and falls back to polling (default every 30s) otherwise, with nothing to configure. The SDK picks whichever is available and the rest of your code cannot tell the difference.

SSE rather than WebSockets is deliberate. Inbox updates travel in one direction, server to client; the writes (mark read, change a preference) are ordinary REST calls that want normal request semantics anyway. A one-way transport that runs over plain HTTP, reconnects on its own, and passes through proxies without an upgrade handshake is a better fit than a duplex socket for a problem that is not duplex.

A missed signal is not a missed notification

The stream is an accelerator, never the source of truth. Notifications are persisted before they are streamed, so a client that was offline, backgrounded, or behind a proxy that ate the connection reconciles against the durable inbox over REST on reconnect and catches up.

This is why the fallback is boring rather than degraded: polling reads the same durable inbox the stream announces. The only thing you lose without SSE is latency.

Tuning

<ElaanProvider
  apiBase="https://api.elaan.io/v1"
  tokenProvider={tokenProvider}
  realtime={false}        // force polling
  pollInterval={15000}   // or tune the interval
>

Polling more often costs a request per client per interval, which is the arithmetic worth doing before you lower it: a thousand connected users at a fifteen-second interval is four thousand requests a minute for an unread count that usually has not changed.