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
• ~200 ms delivery latency including enrichment
• Starts at $199/month
• Bidirectional: subscribe to accounts and change filters on the same connection

Frequently Asked Questions

Sources

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

TweetStream Team

Last updated: April 2026