Skippr Docs

Appearance

What Access Skippr Needs to Read from WebSocket ​

June 2026

WebSocket access is mostly about reachability and connection lifetime, with headers mattering only when the upstream service requires them.

Short Answer ​

Skippr needs outbound access to the configured WebSocket URL, any headers the upstream service requires, and a network path that can keep the connection open. The connector does not ask for a separate permission model beyond that, so the real access question is whether the runner can reach ws:// or wss:// and complete the handshake with the same headers the service expects from a normal client.

A simple example is wss://stream.example.com/v1 with an Authorization header carried through an environment variable. If that endpoint is behind a proxy or firewall that cuts idle sessions, the connector may authenticate correctly and still fail as a source because the connection cannot remain open long enough to consume the stream.

Why Teams Struggle with This ​

Teams often treat WebSocket setup like ordinary HTTP polling. That misses the operational constraint that matters most here: the runner has to keep the socket open and healthy, not just prove one request can reach the host.

  • The runner must reach the exact ws:// or wss:// URL from the environment where Skippr runs.
  • Any required headers, such as bearer authorization, have to be present during the handshake.
  • Proxies, firewalls, and idle timeout settings can break the source even after a valid initial connection.
  • If the upstream service supports both stream and batch style behavior, you still need to decide which mode matches how the endpoint behaves.

How Skippr Handles It ​

Skippr keeps the WebSocket access model deliberately small: URL, optional headers, and mode. That makes review easier because there is no hidden polling credential or separate session-management product to reason about.

The docs also encourage header secrets through environment interpolation, which is practical for bearer tokens. Once the first run is stable, you know the handshake, outbound network path, and connection lifetime are all strong enough for the real message stream.

  • Connects directly to a ws:// or wss:// endpoint.
  • Supports additional request headers for upstream auth or routing requirements.
  • Can run in stream or batch mode depending on the source behavior.
  • Keeps auth header values out of skippr.yaml through environment variables.

What the First Useful Version Looks Like ​

The first useful version is one endpoint, one header set, and one runner environment where you can watch the socket stay open through a normal burst of source traffic.

If the connection drops repeatedly, fix the network path before widening the pipeline because WebSocket reliability is part of the access model, not a separate tuning concern.