Does Twitter/X Use WebSockets? A Developer's Technical Guide

The Short Answer: No, Twitter Does Not Use WebSockets

The official X (Twitter) API does not use WebSockets for its streaming endpoints. Instead, it uses HTTP streaming — a long-lived HTTP connection where the server sends data incrementally using chunked transfer encoding. This is a fundamentally different protocol from WebSocket (RFC 6455).

This distinction matters for developers building real-time applications. The protocol you use affects latency, reconnection behavior, bidirectional communication, and how you architect your client code.

How Twitter's HTTP Streaming Actually Works

When you connect to the X API's filtered stream endpoint (GET /2/tweets/search/stream), your client opens a standard HTTP request. The server responds with status 200 and begins writing newline-delimited JSON — one tweet per line, indefinitely. Think of it as downloading an infinitely long file.

Between tweets, X sends keep-alive signals (empty newlines) approximately every 20 seconds. If your client does not receive any data for 20+ seconds, it should assume the connection is stalled and reconnect.

• Protocol: HTTP/1.1 with chunked transfer encoding
• Data format: Newline-delimited JSON (NDJSON)
• Direction: Server to client only (unidirectional)
• Keep-alive: Empty newlines every ~20 seconds
• Authentication: Bearer token in HTTP Authorization header
• Connection: One long-lived HTTP response, never closes (until error or disconnect)

How WebSocket Differs from HTTP Streaming

WebSocket (RFC 6455) is a separate protocol that starts as an HTTP upgrade request and then switches to a framed, bidirectional communication channel. Unlike HTTP streaming, WebSocket supports both server-to-client and client-to-server messages on the same connection.

Why This Matters for Real-Time Applications

For trading bots and alert systems, the protocol choice has practical consequences:

• Latency: Both protocols deliver data with similar raw latency. The difference is in overhead — WebSocket frames have 2-14 bytes of overhead vs HTTP chunked encoding's variable overhead.
• Reconnection: HTTP streaming has no built-in mechanism to detect stalled connections. You must implement timeout logic. WebSocket's ping/pong protocol handles this automatically.
• Bidirectional: With HTTP streaming, subscribing to new accounts or changing filters requires a separate HTTP request. With WebSocket, you can send subscription changes on the same connection.
• Browser compatibility: HTTP streaming requires the ReadableStream API for incremental parsing. WebSocket has native browser support and a simpler API.
• Infrastructure: HTTP streaming connections can be interrupted by proxies, load balancers, and CDNs that expect standard request/response patterns. WebSocket connections are designed for long-lived use.

Code Comparison: HTTP Streaming vs WebSocket

// HTTP streaming — X API filtered stream
const needle = require('needle');

const STREAM_URL = 'https://api.x.com/2/tweets/search/stream';

function connect() {
  const stream = needle.get(STREAM_URL, {
    headers: { Authorization: `Bearer ${BEARER_TOKEN}` },
  });

  // Must parse incrementally — standard fetch() won't work
  stream.on('data', (chunk) => {
    const line = chunk.toString().trim();
    if (!line) return; // Keep-alive newline
    const tweet = JSON.parse(line);
    console.log(tweet.data.text);
  });

  // No built-in reconnect — you must handle this yourself
  stream.on('error', () => {
    console.error('Connection lost, reconnecting...');
    setTimeout(connect, 5000);
  });
}

connect();

// WebSocket — TweetStream (from $199/mo)
function connect() {
  const ws = new WebSocket('wss://ws.tweetstream.io/ws', [
    'tweetstream.v1',
    `tweetstream.auth.token.${API_KEY}`,
  ]);

  ws.onmessage = (event) => {
    const envelope = JSON.parse(event.data);
    if (envelope.t === 'tweet' && envelope.op === 'content') {
      console.log(envelope.d.text);
      // Enrichment data (tokens, OCR, prices) in meta messages
    }
  };

  // Reconnect in application code when the socket closes
  ws.onclose = () => {
    console.log('Reconnecting...');
    setTimeout(connect, 1000);
  };
}

connect();

WebSocket Services as Twitter Streaming Alternatives

Several third-party services relay Twitter data over true WebSocket connections, bridging the gap between Twitter's HTTP streaming and the WebSocket protocol that most real-time applications prefer.

TweetStream, for example, connects to Twitter data sources server-side and delivers tweet alerts to your application over a standard WebSocket connection. This gives you the familiar WebSocket API (onopen, onmessage, onclose) plus enrichment like OCR, token detection, and live prices.

• Standard WebSocket API — no HTTP streaming parsing required
• Straightforward reconnect handling in client code
• About 200ms detection before enrichment updates
• Starts at $199/month
• Bidirectional: subscribe to accounts and change filters on the same connection

Build it faster with TweetStream

This guide explains the workflow, but production teams should not rebuild tweet ingestion, reconnects, token detection, OCR, and downstream delivery from scratch. TweetStream is the better production starting point: tracked-account events, enriched JSON payloads, history on supported plans, and a 3-day trial you can test against your own accounts.

Frequently Asked Questions

Sources

• X API streaming documentation
• WebSocket protocol (RFC 6455)
• Consuming streaming data (X Developer)

TweetStream Team

Last updated: March 2026