Skippr Docs

Appearance

What Network Access Skippr Needs for WebSocket ​

June 2026

WebSocket source access means the runner can reach the exact WebSocket URL, send any required headers, and keep the connection open long enough to ingest messages.

Short Answer ​

Skippr needs outbound access to the exact WebSocket URL, including the host, port, and HTTP path behind that stream. The connector docs define the source around a url like ws://localhost:8080/stream, optional headers, and a stream-oriented connection, so the operational boundary is the full WebSocket endpoint rather than just a hostname that happens to answer on the network.

That detail matters because WebSocket sources fail at the handshake boundary more often than at the TCP boundary. A runner may reach stream.example.com and still fail if the real stream lives at /v1/events, expects wss:// instead of ws://, or requires an Authorization header on the upgrade request. The source is only ready when the runner can complete that handshake and keep the connection open without a proxy or firewall cutting it off.

Why Teams Struggle with This ​

WebSocket access problems are usually boundary problems: the wrong URL shape, a missing header, or an environment that allows a short-lived handshake but not a stable long-lived connection.

  • The runner must reach the full WebSocket URL, not just the host name.
  • The endpoint may require ws:// or wss://, and using the wrong scheme breaks the handshake.
  • Any required headers have to be present on the connection request, not added later.
  • Proxies, firewalls, and idle timeouts can drop a stream that looked healthy during a quick test.

How Skippr Handles It ​

Skippr keeps this boundary transparent by exposing the full url, optional headers, and mode. That is helpful because infrastructure teams can review a real destination path such as wss://stream.example.com/v1 instead of a vague request for streaming access.

It also makes troubleshooting much more concrete. If the URL is right, the headers are right, and the connection still drops, you can focus on keepalive behavior or middleboxes. If the handshake itself fails, the problem is almost always the scheme, path, auth header, or endpoint reachability.

  • Uses one explicit WebSocket URL with scheme, host, port, and HTTP path.
  • Supports additional request headers for auth or upstream tenancy requirements.
  • Keeps the source in stream mode by default for long-lived message ingestion.
  • Makes connection persistence part of the source contract instead of an afterthought.

What the First Useful Version Looks Like ​

The first useful version is one concrete WebSocket URL, one header set if needed, and a runner environment that can keep the connection open long enough to observe real messages.

If the stream still drops under ordinary load, treat that as a source readiness problem. Downstream work is pointless until the connection is stable.