Skippr Docs

Appearance

How to Manage WebSocket Source Credentials in Skippr ​

July 2026

Keep WebSocket source credentials safe by leaving the endpoint and stream mode in config, interpolating any secret header values from env vars, and matching the connector to the upstream service header model.

Short Answer ​

Manage WebSocket source credentials in Skippr by keeping url and mode in config and treating only secret header values as secrets. The docs show headers as the auth surface, so a safe setup uses environment interpolation for values such as ${WEBSOCKET_AUTH_HEADER} while leaving the rest of the connector readable.

That matters because WebSocket auth is optional and upstream-specific. Some streams are open inside a trusted network, while others require an Authorization header or another request header on the opening handshake. Skippr should mirror that documented service contract instead of hiding the entire connection under one opaque secret.

Why Teams Struggle with This ​

WebSocket credential handling gets sloppy when teams paste bearer tokens into YAML or hard-code them into wrapper scripts. The actual secret is usually one header value, not the URL, not the mode, and not the fact that the source is a WebSocket at all.

  • Committing a literal bearer token or API key in headers exposes the credential immediately.
  • The stream URL should stay visible because it tells operators which service the runner must reach.
  • Different upstream services expect different header names, so a generic secret wrapper can hide a broken handshake.
  • If proxies, firewalls, or idle timeouts keep dropping the connection, rotating the header value will not solve the real issue.

How Skippr Handles It ​

Skippr keeps the connector honest by exposing the WebSocket URL, request headers, and mode directly in source config. That makes it easy to review how the handshake works while still protecting the one header value that needs secret storage.

This is also friendlier for operations. You can inspect the endpoint and connection mode during an incident without retrieving or displaying the token that authorizes the stream.

  • Uses ${WEBSOCKET_AUTH_HEADER} or another env-backed header value for secret material.
  • Keeps url and mode visible so the connection contract is easy to review.
  • Supports authenticated and unauthenticated WebSocket sources with the same config shape.
  • Matches the upstream header model instead of replacing it with a generic connector token story.

What the First Useful Version Looks Like ​

The first useful version is one ws:// or wss:// endpoint, one required header value, and one steady connection test. That proves both the handshake and the runtime network path.

If the upstream service later adds more headers, keep only the secret-bearing values in env vars and leave the header names visible so reviewers can still see what the source expects.