1. Your backend creates a stream session
Call POST /v1/sessions with mode = stream and a profile such as gaming.
Stream Mode
Beam stream mode rides on the same relay, signaling, and WebRTC bridge as regular screensharing, but it is documented and exposed as a separate public session mode so your product can ask for motion-friendly settings and a cleaner viewer experience.
| Profile | Target | Recommended use |
|---|---|---|
balanced |
45 fps / 14 Mbps | General live app sessions and polished demos. |
crisp |
30 fps / 16 Mbps | Readable UI where clarity matters more than speed. |
low_latency |
30 fps / 8 Mbps | Interactive remote control and support-sensitive flows. |
gaming |
60 fps / 18 Mbps | Games, creative tools, fast transitions, and richer motion. |
POST /v1/sessions
Authorization: Bearer YOUR_BEAM_API_KEY
Content-Type: application/json
{
"mode": "stream",
"stream_profile": "gaming",
"audio_enabled": true,
"purpose": "live app demo",
"metadata": {
"build_id": "2026.06.07",
"app_slug": "beam-studio"
}
}
Stream mode pairs well with browser viewing because the control-plane response already returns the WebRTC signaling URL, viewer protocols, and recommended settings. That lets your product drive the whole join experience without handing the user off to a separate meeting brand.