A stream key is a secret alphanumeric token that identifies and authorizes one specific live channel when an encoder pushes video to an ingest server. In streaming and broadcasting, the encoder combines the key with a server URL, and the platform uses it to decide which channel, account and event the incoming feed belongs to.
The key works like a combined username and password for a single outbound stream. Anyone who holds it can broadcast to that channel, which is why platforms hide it by default, allow it to be reset instantly and increasingly pair it with additional controls such as short-lived tokens or IP restrictions.
How a stream key authorizes a live video feed
A stream key authorizes a feed at the moment the encoder opens a publishing session with the ingest server. With RTMP, the most common contribution protocol for platform streaming, the encoder connects to an address such as rtmp://ingest.example/live and then sends the key as the stream name in the publish command. The server looks the key up, maps it to a channel and either accepts or rejects the session.
Once accepted, the server binds the incoming packets to that channel for the rest of the session. Transcoding, recording, chat, and the public player all attach to that binding, so the key is effectively the routing label for the whole pipeline. If the encoder disconnects and reconnects with the same key within the platform’s grace window, the stream usually resumes on the same event rather than creating a new one.
Other protocols carry the same idea in different fields. The table below shows where the key travels in the main contribution protocols.
| Protocol | Where the key appears | Transport protection |
|---|---|---|
| RTMP | Stream name in the publish command | None; plain TCP |
| RTMPS | Stream name inside a TLS session | TLS encryption |
| SRT | Stream ID field or passphrase | Optional AES encryption |
| WHIP (WebRTC) | Bearer token in the HTTP request | HTTPS and DTLS |
| HLS push ingest | Path segment or token in the URL | HTTPS when configured |
The key is not a stream setting. It does not define resolution, bitrate or codec; those come from the encoder profile and the platform’s ingest limits. It only answers the question of who is allowed to publish where.
Types of stream keys and their lifetimes
Stream keys differ mainly in how long they stay valid and how many events they can serve. Platforms offer several models, and production teams choose between them based on schedule, staffing and risk.
| Key type | Validity | Typical use |
|---|---|---|
| Persistent key | Until manually reset | Recurring shows, always-on channels |
| Per-event key | One scheduled broadcast | Webinars, concerts, sports fixtures |
| Expiring signed token | Minutes to hours | Enterprise and pay-per-view ingest |
| Multiple named keys | Each until reset | Separate cameras, backups or regions |
| Backup or redundant key | Paired with a primary key | Failover to a second ingest point |
A persistent key is convenient because the encoder configuration never changes, but it also means a leaked key stays useful to an attacker until someone notices and resets it. Per-event keys limit exposure to one broadcast and suit organizations that schedule streams in advance. Signed tokens embed an expiry time and a cryptographic signature, so the server can verify them without a database lookup and reject them automatically after they lapse.
Stream key compared with related streaming credentials
The stream key is one of several values that a live workflow needs, and confusing them is a frequent setup error. The key controls ingest, meaning the path from the broadcast encoder into the platform; it has nothing to do with how viewers receive the output through HLS, MPEG-DASH or adaptive bitrate streaming.
| Credential | Direction | Purpose |
|---|---|---|
| Stream key | Encoder to platform | Authorize and route one live feed |
| Server URL | Encoder to platform | Locate the ingest endpoint |
| Playback URL | Platform to viewer | Deliver the finished stream |
| API key | Software to platform | Manage channels, events and settings |
| SRT passphrase | Encoder to receiver | Encrypt the transport itself |
An important distinction is between authorization and encryption. A key sent over plain RTMP authorizes the session but travels in clear text, so anyone who can capture the traffic can read it. RTMPS and SRT with a passphrase add transport encryption, which protects both the key and the media.
Configuring a stream key in practice
Configuring a stream key means pasting two values into the encoder: the server URL and the key. Software encoders such as OBS Studio or vMix and hardware encoders offer separate fields for both, and many platforms provide a single combined URL for devices that accept only one field.
- Copy the ingest server URL for the nearest or recommended region.
- Copy the stream key from the platform dashboard without trailing spaces.
- Enter both in the encoder and match the platform’s codec, bitrate and keyframe interval limits.
- Start the stream in a private or unlisted preview to confirm the key routes to the correct event.
- Store the key in a password manager rather than in shared documents or screenshots.
For multistreaming, each destination needs its own key. A relay service or a multi-output encoder holds several keys at once, so it should be treated as a sensitive credential store with restricted access.
Security risks and common mistakes with stream keys
The main risk is unauthorized broadcasting: a leaked key lets anyone stream content to the channel, which can lead to copyright strikes, offensive material on an official account or a hijacked event. Most leaks are accidental rather than technical.
| Symptom | Likely cause | Fix |
|---|---|---|
| Unknown stream appears on the channel | Leaked key | Reset the key immediately |
| Encoder rejected at connect | Wrong key or expired token | Copy a fresh key from the dashboard |
| Feed lands on the wrong event | Persistent key reused | Use per-event keys for scheduled shows |
| Key visible in a recording | Settings window captured on screen | Hide encoder settings during capture |
| Two encoders fighting for one channel | Same key on two devices | Assign a backup key for redundancy |
Good practice is to reset the key after staff changes, after any shared screen session that showed encoder settings and after contractors finish an event. Platforms that support two-factor authentication on the account protect the dashboard where keys are issued, which matters as much as protecting the key itself.
The short version
A stream key is like the key to a specific broadcast studio. The server address tells your streaming software which building to go to, and the key opens the door to your own studio inside it. Without the right key, the platform does not know where your video belongs and refuses to let it in.
Because the key is all that is needed to go live on your channel, treat it like a password. Do not share it, do not show it on screen and change it if you think someone else has seen it.
Where it makes a difference
A university media team streams weekly lectures and a large annual graduation ceremony. For lectures, they use a persistent key stored in the lecture hall encoder, so staff only press start. For graduation, they create a dedicated per-event key and a backup key, feed a hardware encoder at 1080p with a 6 Mbit/s bitrate over RTMPS and run a second encoder on a separate network connection.
During the ceremony, the primary connection drops for 40 seconds. The platform switches to the backup ingest automatically, and viewers see only a brief quality change. After the event, the team deletes the per-event keys, so the credentials shared with an external camera crew stop working immediately.