WebSockets PRO

Requires HTTPBot Pro.

WebSockets let you open a persistent, two-way connection to a server and exchange messages in real time — in both directions — over a single long-lived connection. They're ideal for chat backends, live dashboards, multiplayer state, and any API that pushes updates as they happen.

HTTPBot has a dedicated WebSockets area for creating and running these connections, separate from regular HTTP requests.

An open WebSocket connection showing the event log with sent and received messages and the message input at the bottom

Creating a WebSocket request

Open the WebSockets tab (in the sidebar on iPad/Mac, or the tab bar on iPhone) and create a new WebSocket request. A WebSocket request looks much like an HTTP request: it has a URL bar, and you can add headers, authentication, and variables, just as you would for an HTTP request.

The key difference is the URL scheme. WebSocket URLs use:

ws:// for an unencrypted connection, or
wss:// for a secure (TLS) connection — the recommended default.

wss://echo.websocket.org

URLs support {{variable}} placeholders, so you can keep the host in an Environment and switch between, say, staging and production.

Connecting

With a ws:// or wss:// URL entered, tap Send (shown as Connect) to open the connection. The status moves through:

Connecting — HTTPBot is performing the WebSocket handshake.
Connected — the connection is open and ready to exchange messages.

If the handshake fails (bad URL, server unreachable, TLS problem), HTTPBot shows an error describing what went wrong.

To close the connection, tap Stop (shown as Disconnect). HTTPBot closes the socket cleanly and records a disconnection event in the log.

The connection status reading Connected once the handshake completes

Sending messages

Once connected, a message input appears at the bottom of the screen. You can send two kinds of messages:

Text messages — type your message into the input and tap the send button. This is the common case for JSON or plain-text protocols.
Binary messages — tap the + button to attach a file from your device; its raw bytes are sent as a binary frame.

Each message you send is added to the event log immediately and marked as a sent message.

{ "type": "subscribe", "channel": "prices" }

The event log

The body of the WebSocket view is a chronological event log. Both received and sent messages appear here, each annotated with:

A timestamp for when it occurred.
Its direction — whether it was sent by you or received from the server.
Its content — the text or a description of the frame.

The log isn't limited to messages: connection lifecycle events show up too, so you can see when the socket connected, disconnected, or hit an error, along with ping/pong activity. This makes the log a complete record of the session for debugging.

The event log with a connected event, an outgoing message, and several incoming messages

Settings

WebSocket requests have their own settings:

Handshake Timeout Interval in Seconds — how long HTTPBot waits for the initial connection handshake before giving up.
Verify SSL — on by default. Turn it off to allow connections to servers with self-signed or otherwise untrusted certificates (useful for local development). Leave it on for production endpoints.

For more on certificate handling and the global request settings, see Request Settings.

Tips

Use wss:// whenever possible; only fall back to ws:// for local testing.
If a secure connection to a development server fails on certificate validation, turn off Verify SSL for that request rather than weakening your whole setup.
Keep an eye on the event log's lifecycle entries — an unexpected disconnected or error event usually explains why messages stopped flowing.