Broadcasting your demo to your store page

16 Jul 2026 · 5 min read

The trap: you're broadcasting demo footage, but the App ID has to be the base game's

It is tempting to configure the broadcast against the demo's own App ID, since that is the app you are actually running and capturing footage from. Valve's documentation is explicit that this does not work: "A livestream of the demo appID will not automatically appear on the base game's store page." The demo and the base game are two separate App IDs in Steam's system, and a broadcast pointed at one does not carry over to the other.

It's worth being clear that this is a demo-specific problem, not a general broadcasting one. If you're streaming a released game to its own store page, there's only one App ID in the picture, so there's nothing to target incorrectly. The trap only exists because a demo introduces a second App ID that produces footage but isn't the one visitors actually browse to - and that gap between "what you're capturing" and "what you're publishing to" is unique to the demo-to-base-game setup.

The fix is to configure the broadcast against the base game's App ID, even though the footage on screen is the demo's. That distinction - which app you're capturing versus which app you're broadcasting to - is the whole trap, and it's why "my stream isn't showing up" during a Next Fest push is almost always a targeting problem, not a technical one. Nothing about the video itself is wrong in this scenario: the encode is fine, the RTMP handshake succeeds, and the stream is genuinely live. It's just live against the wrong App ID, so no store page ever picks it up. The full setup steps are in Valve's own guide, Livestreaming a Game Demo to the Steam Store.

Two mechanics compound the confusion here. First, changing the Broadcast App ID in your stream settings applies immediately on Steam's side, but the store page itself can take a short while to catch up - if you've just fixed a wrong App ID and the page still looks empty a minute later, that's ordinary propagation lag, not a sign you got the fix wrong. Give it a few minutes before you start second-guessing the App ID you just set. Second, Valve's own broadcast FAQ narrows the entire "why isn't my stream showing" question down to exactly two causes: the account isn't whitelisted for the game, or the Broadcast App ID is unset or wrong. Everything in this article is really an elaboration of that second cause. The App ID mismatch above is one specific way to get it wrong; account whitelisting, covered next, is the other.

A second trap: don't play the demo on the account you broadcast from

Valve's documentation carries a second warning that catches people even after they've fixed the App ID: "Do not play the Demo app using the same Steam Account you plan to use for broadcasting." Steam's client prioritizes whatever game is currently running on an account over that account's configured broadcast settings. If the account you're broadcasting from is also the account actively playing the demo, the running demo session takes precedence and overrides your base-game configuration.

The practical fix is to keep the two separate: don't have the demo running live on the account you use to authenticate the broadcast, whether that authentication happens through OBS or a hosted service. Capture or source the footage another way, and let the broadcasting account do only the broadcasting. This is one place where an uploaded-video loop has a natural advantage over a live capture setup - if nothing is being played on the broadcasting account in the first place, there's no running game to compete with the broadcast configuration.

A natural workaround suggests itself here: spin up a second, throwaway Steam account just to hold the demo session, and keep broadcasting from your main one. That does solve the running-game conflict - but it walks straight into a different failure mode, covered next, because a brand-new account clears almost none of Steam's actual bar for who's allowed to broadcast at all.

Why you get "your account does not have sufficient privileges to broadcast"

This is the single most common complaint about store broadcasting on Steam's own forums, and it has nothing to do with App IDs or which account is playing what. Steam checks the broadcasting account itself against four separate conditions, and all four have to be true at once.

The account must be non-limited, which on Steam specifically means it has spent at least $5 USD historically - on a game, a DLC, a wallet top-up, anything. This is exactly what catches the burner-account workaround from the section above: an account created purely to hold a demo session is, by definition, a fresh limited account with no purchase history, and Steam rejects it rather than explaining why in any useful way. If you do use a second account to separate the demo session from the broadcast, that account needs its own $5 of real spending history before it's eligible for anything broadcast-related.

Separately, the account needs explicit broadcast permission, granted one of two ways: "Broadcast Live" permission set for that account in Steamworks, or membership in the Store Broadcast Beta group. Neither is on by default, and this is distinct from owning the game - an account can legitimately own a copy and still lack permission to broadcast with it until one of these two is granted.

On top of that, the account needs a real relationship to the game itself: a purchase or product key, Steamworks Partner Group membership with access, or a release-override license if the title hasn't shipped yet. And it must not be Community Banned - a ban on the account overrides everything else on this list, regardless of spend history or granted permissions.

Steam's error message when any one of these four fails - "your account does not have sufficient privileges to broadcast live streams" - doesn't say which one. The full breakdown is in Valve's setup guide, Setting Up Steam Broadcasting. Worth ruling out all four before you assume the App ID or RTMP configuration is at fault, since an eligibility failure looks identical to a targeting failure from the outside: the stream just doesn't appear.

Separately from account eligibility, the base game's store page also needs to have granted broadcast access in the first place, through Steam Event setup or the store page's Special Settings. An eligible account and a correct App ID still won't produce a visible broadcast if the store page itself hasn't been told to accept a stream - a third, independent switch that has to be on alongside the other two. In practice that's granted from one of two places in Steamworks: a scheduled Steam Event configured to include broadcast access, or the store page's own Special Settings panel. Either is enough on its own - you don't need both - but at least one of them has to be set, and it's easy to assume the App ID field alone covers it when it doesn't.

The Steam client's built-in broadcast can't do this

Valve is direct about this too: "You cannot use the Steam Client built-in broadcasting feature to Stream demo gameplay to the Steam Store." The broadcast tab you'd normally use to stream to your own profile doesn't apply here at all. Whatever pushes the demo footage to the store page has to be external - OBS pointed at your streaming account's RTMP server and stream key, or a hosted service that ingests a video and pushes it for you. Either way, the server URL and the key are the two values everything downstream depends on, and they belong to the streaming account specifically, not the game. Pull yours before you start; see where to find your Steam stream key if you haven't already.

This isn't an arbitrary restriction. The built-in broadcast tab ties itself to whatever game session is currently active on your account - the exact mechanism behind the same-account trap above, which always prioritizes the running game over any external configuration. An external encoder doesn't have that problem, because it isn't tied to a Steam game session at all. It just pushes an RTMP stream to whatever server and key you give it, independent of whether anything is running on the account, or what.

If the plan is to keep the demo live on the store page for the length of a whole event rather than a single session, a hosted loop is the version of this that doesn't need a machine left running an encoder in the background; see how pricing works.

Timing: this works before your base game launches, and it doesn't stop exactly on schedule

Demos are usually attached to unreleased games, which raises the obvious question of whether the broadcast is even allowed before the base game is out. It is: games with a Coming Soon page can stream ahead of release, which is exactly the situation most Next Fest demos are in. The Coming Soon status on the store page is what unlocks pre-launch broadcasting - it isn't a separate flag you set yourself - so if your page isn't marked Coming Soon yet, that's worth fixing before you troubleshoot anything else on this page. The pre-launch specifics, separate from the demo-targeting question above, are covered in broadcasting before launch, on a Coming Soon page.

The other timing detail worth knowing sits at the other end of an event: Valve allows a broadcast to keep running for up to 24 hours past a scheduled event's end time. So a Next Fest demo stream still live the morning after the festival officially closes isn't a bug - it's inside Valve's own grace window, not something you need to scramble to cut the instant the countdown hits zero. Plan your own wind-down around that number rather than around the festival's listed end time.

If your broadcast plan spans a full festival rather than a one-off test, the event mechanics themselves are covered in broadcasting for Steam Next Fest. This article exists alongside that one because Valve's own documentation doesn't dwell on the traps that actually cause a demo broadcast to go live and appear nowhere - the App ID mismatch, the same-account conflict, and the four-part account eligibility bar above are the unglamorous, practical reasons setups fail, and none of them produce an error message that names itself.