Skippr Docs

Appearance

When to Use WebSocket as a Source Connector ​

June 2026

The WebSocket source connector is best when the upstream data source is already a live socket stream and the team wants to ingest messages directly from that stream.

Short Answer ​

Use the WebSocket source connector when the upstream service already exposes a live ws:// or wss:// feed and the right integration pattern is to consume pushed messages rather than poll an API or wait for files. It is a strong fit for real-time operational feeds, application event streams, or vendor services that treat a socket connection as the primary delivery mechanism.

A practical example is a streaming product feed that requires one Authorization header and keeps sending messages as state changes happen. Skippr can connect to that URL, pass the needed headers, stay in stream mode, and hand those messages to a downstream destination without forcing the team to wrap the feed in a separate relay service first.

Why Teams Struggle with This ​

WebSocket integrations are only pleasant when the connection behavior is stable. Network path, handshake requirements, and connection longevity are part of the source choice, not just operational cleanup after the fact.

  • The runner must be able to reach the target host and port and keep the connection open.
  • If the upstream service expects headers such as Authorization, they need to be managed cleanly through environment variables.
  • Proxy or firewall behavior can break long-lived connections even when a quick connectivity test succeeds.
  • WebSocket is a bad fit when the feed drops frequently and the upstream provider does not offer a stable enough stream contract to build on.

How Skippr Handles It ​

Skippr keeps the connector aligned with the actual source surface: URL, optional headers, and mode. That is enough to make a live socket feed part of an ordinary ELT or streaming setup without pretending it is just another poll-based API.

This is especially helpful when the organization already has one event stream it trusts and does not want to insert a custom proxy just to make that stream look more conventional.

  • Connects directly to ws:// or wss:// endpoints.
  • Supports custom request headers such as Authorization.
  • Runs in stream mode by default for live message ingestion.
  • Fits integrations where a persistent socket is the actual upstream delivery contract.

What the First Useful Version Looks Like ​

The first useful version is one stable WebSocket URL, one authentication header if needed, and one destination that proves the incoming message schema is coherent enough to use downstream.

WebSocket is a bad fit when connection drops are routine, when proxies interfere with long-lived sockets, or when the same data is available through a more durable batch or database interface that would be easier to operate.