TL;DR

The Eloqra chat widget refreshes by asking the server for updates every few seconds over plain HTTP, rather than keeping a live socket open.

Key Points

✓

Short polling sends a new request at a fixed interval and the server replies immediately, with data or an empty response, regardless of whether anything changed [1][2].

✓

Eloqra's [[live-chat-widget]] polls a /messages endpoint about every 4-5 seconds for new [[chat-message]] entries and pings /typing to drive the [[typing-indicator]].

✓

Because each poll is a normal HTTP call, it works behind proxies and firewalls that may block a [[websocket]], at the cost of small repeated header overhead [1][4].

✓

Updates are not instant: a new operator reply can wait up to one poll interval before it appears in the [[conversation]], a deliberate simplicity-for-latency tradeoff [3].

✓

Polling is independent of how operators reply; answers arrive via the [[telegram-integration]] [[webhook]] and are simply picked up on the visitor's next poll.

✓

It pairs with Eloqra's [[rest-api]] style endpoints, keeping the widget stateless and easy to embed via the [[embed-code]] without socket infrastructure.

How polling works in Eloqra

Eloqra deliberately uses HTTP short polling rather than a WebSocket. After the Live Chat Widget boots inside its Shadow DOM, it runs a timer that issues a request roughly every 4-5 seconds to a /messages endpoint and a lightweight /typing ping. The server answers each request right away, returning any new Chat Message records and the current Typing Indicator state, or an empty payload when nothing changed ^[1]^[2]. This client-initiated loop means the server never pushes unprompted; the visitor's browser is always the one asking. For a Live Chat tool aimed at indie hackers, the appeal is operational simplicity: there is no long-lived connection to keep alive, scale, or reconnect.

Why polling instead of WebSocket

A WebSocket keeps a persistent, full-duplex channel open so the server can deliver messages the instant they exist, with minimal per-frame overhead ^[2]. Polling trades that immediacy for robustness and ease: plain HTTP requests pass through proxies, corporate firewalls, and CDNs that sometimes block sockets ^[4]. The cost is latency and repeated header traffic, since each poll carries full HTTP overhead even when idle ^[1]. RFC 6202 notes that long polling reduces some of this waste by holding a request open until an event occurs, but at the price of more complex connection handling ^[3]. Eloqra favours the predictable, stateless short-polling model so the widget stays tiny and dependency-free.

What this means for response times

Because the widget only learns about updates on its next request, there is an inherent gap between when something happens and when the visitor sees it. When a Support Operator answers from Telegram, the reply travels back through the Telegram Integration Webhook, is stored against the Conversation, and then surfaces on the visitor's following poll, typically within the 4-5 second window. The same applies to the operator-side Typing Indicator and unread counters. For asynchronous, human-paced support conversations this delay is rarely noticeable, which is why short polling is a sensible default rather than a limitation for Eloqra's Website Visitor chats ^[1]^[3].

Sources & References

WebSocket vs Long Polling - WebSocket.org ↗

WebSocket API - MDN Web Docs ↗

RFC 6202: Best Practices for Long Polling and Streaming in Bidirectional HTTP ↗

What is HTTP Long Polling - and is it still relevant today? - Ably ↗

Last updated: June 25, 2026

Related Terms

WebSocket

WebSocket is a protocol (standardized as RFC 6455) that opens a single, persistent, full-duplex connection between a browser and a server, letting either side push data at any time without re-issuing HTTP requests. It is the transport many real-time apps reach for when they need low-latency, bidirectional messaging.

Live Chat Widget

A live chat widget is the embeddable, in-browser chat interface a website loads from a small script so visitors can message a business in real time without leaving the page. In Eloqra it is a floating launcher and chat panel that boots from a single <script> tag and renders inside a Shadow DOM.

Webhook

A webhook is a user-defined HTTP callback: instead of polling for data, an application registers a URL that a source service calls with an HTTP POST request the moment a specific event happens. [1] In Eloqra, a webhook is how an operator's Telegram reply travels back into the chat widget.

REST API

A REST API is a web interface that lets two systems exchange data over HTTP by treating each piece of data as a resource addressed by a URL and acted on with standard methods like GET, POST, PUT, and DELETE. It follows the Representational State Transfer architectural style, which favors stateless, uniform, cacheable interactions between client and server.

Telegram Integration

Telegram Integration is the mechanism by which Eloqra routes every website chat into the project owner's Telegram, forwarding visitor messages to a Telegram bot and flowing operator replies back to the widget. It turns Telegram into the operator inbox, so there is no separate agent console to keep open.

Typing Indicator

A typing indicator is a real-time visual cue, usually an animated three-dot ellipsis, that tells one side of a chat that the other side is actively composing a message [3]. In Eloqra it works both ways: the visitor sees an operator is typing, and the operator sees the visitor is typing.

Collect testimonials that build trust

Eloqra gives you a lightweight live chat widget that routes every visitor message to your Telegram — free while in early access.

Get Started Free

HTTP Polling