Skippr Docs

Appearance

How WebSocket Source Authentication Works in Skippr ​

June 2026

WebSocket source authentication is optional in Skippr, but when a service expects headers such as Authorization, the handshake has to carry the exact values the upstream server checks.

Short Answer ​

WebSocket source authentication in Skippr is optional and upstream-defined. The connector lets you set a url and additional headers, which means the common auth pattern is a header such as Authorization: Bearer ... passed from an environment variable like WEBSOCKET_AUTH_HEADER rather than a fixed connector-specific username and password.

That is a good fit for event services that already publish over ws:// or wss://. If a stream at wss://stream.example.com/v1 expects a bearer token during the opening handshake, Skippr can send that header directly. The source is only truly authenticated when the upstream service accepts the handshake and the runner can keep the connection open long enough to receive messages.

Why Teams Struggle with This ​

Teams often under-specify WebSocket auth because the connector surface is small. The docs make the real contract clearer: the URL must be reachable, any required headers must be present, and the network has to support a stable long-lived connection after authentication succeeds.

  • Authentication may be absent entirely or may depend on request headers supplied in headers.
  • Sensitive header values should come from environment interpolation rather than sitting inline in config.
  • The correct choice between ws:// and wss:// is part of successful authentication because the handshake has to match the server expectation.
  • A handshake can succeed and still be operationally weak if proxies or firewalls drop the connection immediately afterward.

How Skippr Handles It ​

Skippr gives WebSocket sources a clean auth model because it does not pretend every service authenticates the same way. You supply the URL and headers the upstream server actually expects, which keeps the source definition aligned with the service contract instead of forcing it into a database-style credential form.

That also makes troubleshooting practical. If the source fails, you can check the exact handshake inputs: URL scheme, header names, header values, and network stability. Those are the real variables in a WebSocket auth setup.

  • Optional authentication through request headers such as Authorization.
  • Environment-backed header values like ${WEBSOCKET_AUTH_HEADER}.
  • Support for both ws:// and wss:// endpoints depending on the upstream service.
  • A documented requirement that the runner can reach the host and keep the connection open.

What the First Useful Version Looks Like ​

The first useful version is one URL, one required header set, and one runtime environment that can hold the stream open. That proves the auth model and the transport model together.

If the service uses proxies, idle timeouts, or firewall rules, test from the same place the pipeline will run. WebSocket authentication is only useful when the connection survives after the handshake.