Streamloop

Reviewed 1d ago.

• tools: 67 tools scanned
• metadata: scanned

No findings.

Tools (67)

• list_streams

  Find streams and their ids — the starting point for every other stream tool. Each row carries the name, current state, scheduled start and whether that schedule repeats, which is enough to tell a one-off from a daily loop without a second call. Filter by name substring, status (active = live or starting, scheduled = waiting for its window, inactive = neither) and creation window. Use get_stream for one stream's full configuration.

• get_stream

  One stream's full configuration: current state, output quality and framerate, the destinations it publishes to (each enabled or not, with its delivery state), and its scheduled window including recurrence and repeat weekdays. Use it before changing a stream. For whether it could start right now, call check_stream_readiness instead (this tool reports what is configured, not what is missing); for live viewer numbers, get_stream_live_stats.

• start_stream

  Start streaming now, looping the stream's playlist (or playing its scene) until it is stopped. THIS PUTS VIDEO IN FRONT OF THE PUBLIC, so confirm with the user first unless they just asked for it. Requires a destination plus either a playable video playlist (at least one item) or an attached published scene (set_stream_scene) — check_stream_readiness reports what is missing without changing anything, and is worth calling first. A failed pre-flight is NOT an error: the call succeeds and the answer's `state` is `invalid` — read `state` first: invalid means refused, with `issues` saying why (fix them and start again); `preparing` means accepted. Media facts (duration, sound) arrive about 15-25 s after an upload completes, so a playlist of just-finished uploads can be refused until then. Other refusals (a state that cannot start, a guard failing at the moment of starting) are errors. Credits are NOT part of the pre-flight: the balance is verified when the stream actually activates, so an o

• stop_stream

  Stop a stream that is live or starting. It stops publishing and becomes inactive; nothing is deleted and it can be started again with the same configuration. Does NOT cancel a recurring schedule — a daily or weekly stream stopped here starts again at its next window, so call cancel_stream_schedule as well to keep it off.

• delete_stream

  Permanently delete a stream, its playlists and its schedule. Irreversible, and it cannot be undone by re-creating the stream: uploads survive but the arrangement does not. Stop the stream first if it is live. To keep a stream but take it off the air, use stop_stream (plus cancel_stream_schedule). Requires confirm=true and the streamloop:destructive scope.

• create_stream

  Use this to set up a new loop or a stream for a scene. The stream is created empty and CANNOT start until it has (1) a destination — add_stream_destination with one from list_destinations, or get_connection_hints for how to make one — plus (2) either a playable video playlist (at least one item) or an attached published scene (set_stream_scene). Creating a stream also creates its two empty playlists (one video, one audio): for a loop, find them with list_playlists(streamId) and fill them with apply_playlist_operations — a playlist loop needs nothing published before the first start. Media facts (duration, sound) of an upload arrive about 15-25 s after it completes: a start right after uploading can be refused (state invalid) until then. When it runs is schedule_stream's job.

• update_stream

  Change a stream's settings (name, quality, framerate, duration, storage, backup ingest) and/or its YouTube broadcast settings via the `youtube` object. Where it publishes is add_stream_destination / set_stream_destination_enabled / remove_stream_destination; when it runs is schedule_stream. The `youtube` settings only apply when one of the stream's destinations is a YouTube channel connected through Streamloop — not a custom RTMP destination, and not YouTube reached through a raw RTMP URL and key — and are otherwise skipped with a notice. Set retryMirror=true to re-attempt mirroring the schedule onto YouTube after a reconnect or a quota recovery. PARTIAL SUCCESS: settings are applied first, so if the YouTube settings then fail, `stream` still reflects the applied settings and `youtubeSettingsError` explains the YouTube failure — the settings change is NOT rolled back.

• schedule_stream

  Set the window a stream runs in, once or on a repeat, and arm it. The stream must already be startable — a destination plus either a playable video playlist or an attached published scene (check_stream_readiness) — otherwise the window arrives and the start fails. repeat=daily re-arms the window exactly 24h later; repeat=weekly re-arms +7 days, or on the weekdays given in `days`. Both repeats REQUIRE scheduleEndAt and a window shorter than 24h; a one-off (repeat=none, the default) may be open-ended. `days` are UTC weekdays of the start instant, so a 9pm Monday Eastern window repeats on TUESDAY — the result echoes the committed window in UTC with its UTC weekday so this is visible. Times must carry an explicit UTC offset. Replaces any existing window; cancel_stream_schedule disarms it.

• cancel_stream_schedule

  Disarm a scheduled stream and return it to an unscheduled, inactive state, clearing any daily or weekly repeat. Use this to stop a recurring stream coming back; it has no effect on a stream that is currently live (stop_stream does that).

• check_stream_readiness

  Answer 'would start_stream work right now?' without changing anything. Runs the same pre-flight configuration checks a start does and returns ready plus every blocking issue — typically a missing or archived destination, an empty video playlist, media too big for the stream's storage, or, for a stream playing a scene, a scene that is missing, not published or invalid. It does NOT check whether uploads have finished processing: a playlist takes only completed uploads, but their media facts (duration, sound) arrive about 15-25 s after an upload completes, so wait that long after uploading before starting. Credits and YouTube live eligibility are deliberately NOT part of it (both are re-checked at the moment the stream activates), so ready=true means correctly configured, not guaranteed to go live — pair it with get_billing_overview when a ready stream still will not start. Call it before start_stream and before relying on a schedule_stream window.

• get_stream_live_stats

  How a live stream is doing ON YOUTUBE: watch URL, broadcast status, concurrent viewers, views and likes. Only meaningful while the stream is live to a YouTube channel connected through Streamloop — a custom RTMP destination reports nothing here, since those numbers live with that platform. For whether Streamloop itself considers the stream healthy, read state from get_stream.

• list_stream_destinations

  Where a stream publishes, in the order they were added: each destination, whether it is enabled, and while the stream runs its delivery state (connecting, live, reconnecting, failed with a reason).

• add_stream_destination

  Make a stream also publish to one of the workspace's destinations (list_destinations), enabled. Up to 5 per stream and one YouTube channel at most (DESTINATION_LIMIT, YOUTUBE_DESTINATION_LIMIT, DESTINATION_DUPLICATE). A second destination needs multistream on the workspace (MULTISTREAM_NOT_ENABLED). Refused while the stream is live (STREAM_LIVE), and for a destination the stream's quality or codec cannot reach (DESTINATION_INCOMPATIBLE).

• set_stream_destination_enabled

  Stop or resume sending to one of a stream's destinations without removing it. Disabling works while the stream is live — that output goes off the air at once — except for its last enabled destination (LAST_DESTINATION: stop_stream instead). Enabling is refused while live (STREAM_LIVE).

• remove_stream_destination

  Take a destination off a stream (the destination itself stays in the workspace). Refused while the stream is live (STREAM_LIVE): disable it with set_stream_destination_enabled instead.

• get_connection_hints

  Use this FIRST when the user names a platform they want to stream to ("put this on YouTube", "also send it to Twitch") and there is no destination for it yet. Returns, for that platform: the connection methods, the exact `ingestUrl` to pass to create_rtmp_destination (or null when the platform issues one per session), what each method can and cannot do afterwards, the Streamloop tools to call in order, where in the platform's own UI the user finds the stream key, and the behaviour that otherwise ends a 24/7 loop early. NEVER guess an ingest url — a wrong host is a stream that silently never connects. Static guidance: it reads nothing, changes nothing and costs nothing. YouTube in particular has TWO answers and they are not equivalent: a managed connection (Google consent, and only then can titles, privacy, thumbnails and viewer counts be managed from here) or a plain stream key (video only).

• list_destinations

  Find the places this workspace can publish to — connected YouTube channels and custom RTMP endpoints — and their ids, which is what add_stream_destination needs. Check `status`: only an `active` destination can carry a stream; `needs_reauth` and `revoked` mean the YouTube connection must be re-consented (start_youtube_connection) before a stream using it will start. Filter by name substring, a single id, status or kind.

• create_rtmp_destination

  Create a destination for any platform that gives out an RTMP ingest URL and stream key (Twitch, Facebook, Kick, X, TikTok, Telegram, a self-hosted server, or YouTube when its channel is not connected here). Take rtmpUrl from get_connection_hints(platform).ingestUrl rather than guessing it — a wrong host is a stream that silently never connects. The key is stored encrypted and never read back. Use create_youtube_destination instead when the channel is connected through Streamloop: only then can titles, privacy and thumbnails be managed from here. Attach the new destination to a stream with add_stream_destination.

• update_destination

  Maintain an existing destination: rename it, replace the stream key after the platform rotated it (custom RTMP only — a connected YouTube channel has no key to set), and archive or restore it. Archiving hides a destination from the picker without deleting it; it is reversible with archived=false. A live stream keeps publishing with the key it started with, so restart the stream after rotating a key. Pass only the fields to change. NOT transactional: each change commits on its own, and on a failure the response lists which ones already applied.

• start_youtube_connection

  Begin connecting a Google account so its YouTube channels can be streamed to with managed broadcasts (titles, privacy, thumbnails, live stats). Returns a Google consent URL — give it to the user to open in a browser; consent cannot be completed by an agent. Afterwards, list_youtube_channels shows the authorized channels and create_youtube_destination turns one into a destination. Also the fix for a destination whose status is needs_reauth or revoked. Not needed for plain RTMP publishing to YouTube — that is create_rtmp_destination, but it cannot manage the broadcast.

• list_youtube_channels

  The YouTube channels this workspace has Google consent for, with live channel data (title, handle, country, subscriber count, connection status). These are NOT destinations yet: pass a channel's `id` to create_youtube_destination to get something a stream can publish to. Use list_destinations to see which channels already have one. An empty result means no Google account is connected — start_youtube_connection.

• create_youtube_destination

  Turn an already-consented YouTube channel into a destination a stream can publish to, with managed broadcasts (update_stream's `youtube` settings, get_stream_live_stats). Takes the channel `id` from list_youtube_channels — NOT the YouTube channel URL or handle. If that list is empty, the account has not consented yet: start_youtube_connection first.

• list_playlists

  Use this to get from a stream to something you can edit: pass streamId and you get the two playlists that stream owns — one video, one audio, created empty with it. Pass sceneId for the playlists a scene's sources play. Also the way to find a playlist id before any other playlist tool. Rows are a summary; get_playlist has the items.

• create_playlist

  An empty playlist owned by a scene, for one of its playlist sources to play (a stream's own two playlists come with the stream). Fill it with apply_playlist_operations. Each call creates another.

• get_playlist

  Use this before editing a playlist (item ids for remove and reorder come from here, and so does the `version` the edit tools take) and after swapping one onto a live stream (to see the swap finished). Returns the draft items in play order, what a running stream is playing right now, whether the draft differs from that, how it differs, and any custom playback order attached.

• apply_playlist_operations

  Use this for every playlist change: add media, remove items, reorder, or switch between sequential and shuffle, as one ordered batch. All-or-nothing — if any operation is invalid, nothing is written. A stream that is NOT currently live picks the change up on its next start, with nothing else to call. A stream that IS live keeps playing the arrangement it started with until swap_live_playlist replaces it. Media ids (obj_...) come from list_uploads; item ids (plitm_...) come from get_playlist. Operations apply in sequence, each seeing the result of the previous, so an index in a later operation must account for the earlier ones. Pass basedOnVersion (the `version` from get_playlist) to be told about a concurrent edit instead of overwriting it.

• copy_playlist

  Use this to reuse an arrangement on a second stream instead of rebuilding it: copies one playlist's contents into another playlist of the same kind. The target must be EMPTY — this never merges or overwrites. The target stream picks the contents up on its next start; if it is already live, swap_live_playlist puts them on the air.

• swap_live_playlist

  Use this ONLY to put an edited playlist on the air while its stream is LIVE — the hot swap the product calls publishing. The stream changes over to the new arrangement without going off the air. NOT needed to set a stream up and NOT needed before a first start: starting a stream takes the playlist as it is then, so on a stream that is not live this tool just fails with NOT_LIVE. Asynchronous — newly added media may have to be encoded first, so poll get_playlist until the swap is no longer in progress. expectedDraftVersion is required (the `version` from get_playlist) so a concurrent edit is reported instead of going live by accident. Other failures name their cause: STALE_DRAFT (refetch and retry), EMPTY_PLAYLIST, BROKEN_ITEM (an item's media was deleted or never finished uploading), RECIPE_MISMATCH, NOT_FOUND.

• list_playlist_orders

  Find saved custom playback orders (order sequencers) and their ids. Use it before creating one — an order the user already has can be assigned to another playlist instead of rewritten. Pass streamId to see only orders that can run over that stream's playlist. `latestReadyVersionID` null means nothing usable has been produced yet. Which order a given playlist is using is on get_playlist, not here.

• get_playlist_order

  One saved order: its description, how many playlists use it, and its newest usable version with any validation problems. Pass playlistId as well to get the answer that actually matters before assigning — whether this order can run over THAT playlist (`assignable`), which items it expects but cannot find, and a dry-run of the first items it would pick, in order. Do that instead of assigning to find out.

• create_playlist_order

  Describe a playback order in plain language and have one written and validated. Pass the playlist it is for as playlistId: the order is written against that playlist's REAL items, so leaving it out produces a rule aimed at nothing. Creating does NOT apply it — assign_playlist_order does. Read `status` on the result: READY = usable; INVALID = written but it failed validation, and `diagnostics` say why (refine it, this is not a transport error); MESSAGE = a clarifying question or refusal, nothing was produced; PENDING = still running, poll get_playlist_order.

• refine_playlist_order

  Continue the conversation about an existing order — 'never end on an instrumental', 'put the announcement second instead' — producing a new version. Use this rather than creating a second order for the same purpose. Pass the playlist currently being composed against so the rewrite sees its real items. Interpret `status` exactly as for create_playlist_order. A new version does NOT reach playlists already using this order: they stay on the version they were assigned, until assign_playlist_order is called again.

• assign_playlist_order

  Make a playlist play in a saved order. This is the step that changes playback, and unlike a playlist edit it needs no swap_live_playlist — a running stream picks the new order up for its next items. The version in use is pinned at assign time and never advances on its own, so call this again after refine_playlist_order to adopt an improvement. Check get_playlist_order(id, playlistId) first: assignment succeeds even when items the order names are missing, returning dependencyWarnings, and those items simply never get picked. Only a rule that cannot run over the playlist at all is refused.

• unassign_playlist_order

  Stop a playlist using a custom order; it returns to playing in its own item order (or shuffled, per the playlist's mode). The order itself is kept and can be assigned again. Like assigning, it takes effect on a running stream immediately, with no swap_live_playlist needed.

• list_uploads

  Find media and their ids (obj_...) — what apply_playlist_operations adds to a playlist. Removed media is not listed. `uploaded` false means the media is still arriving or processing and cannot be streamed yet. Filter by name substring, kind and creation window; use get_upload for one item's duration, resolution and import progress.

• get_upload

  One media file in detail: duration, resolution, framerate, whether it has video and audio (probed from the file itself, not from its name), a temporary download URL, a thumbnail, and — for a URL import — how far the download has got and why it failed. Use it to confirm media is ready to stream, and to read the duration a schedule window has to fit.

• create_upload

  Step 1 of uploading a LOCAL file: reserves the media record and returns `uploadUrl`, a presigned PUT you can use immediately. This server does not relay bytes, but YOU probably can — if the client can run a command or make an HTTP request, do the PUT itself: curl -X PUT -H 'Content-Type: <the mimeType you passed>' --data-binary @<file> '<uploadUrl>' The Content-Type header MUST equal the mimeType given here, or the signature is rejected. The url is valid for about 11 hours and takes the whole file in one request (up to 1.5 GB, 5 GB on a paid plan). If the client cannot make requests, hand `uploadUrl` to the user. Then call complete_upload — media that is never PUT and completed stays unusable. If the file is already reachable over https (including a file the user attached in this conversation), skip all of this and use discover_external_media + import_upload_from_url instead.

• complete_upload

  Step 2 of uploading a local file: call it once the bytes have been PUT to the url create_upload returned — by you, or by the user — which starts processing. Until this is called the media is unusable, and calling it before the PUT finishes leaves a broken record. Nothing to call for a url import: import_upload_from_url completes on its own.

• discover_external_media

  Look at any media url and report what could be imported from it: each asset with its quality options, sizes and duration. REQUIRED BEFORE import_upload_from_url, which takes the opaque asset and quality ids only this tool hands out — they cannot be constructed. Works for a media page AND for a direct file link, which is what makes it the right tool for a FILE THE USER ATTACHED in this conversation: pass the attachment's https url and import from it, with no local file and no PUT. Reads the url only; nothing is imported and no credits are spent. Import only the user's own or otherwise licensed content.

• import_upload_from_url

  Import chosen assets from a media url — a page, a direct file link, or a file the user attached in this conversation — straight into the workspace, with no local file and no PUT. Each selection must echo an assetId and qualityId from discover_external_media for the SAME url; invented ids are rejected. One selection produces one media item, so the same asset can be imported twice with different ranges to get two clips. Downloading is asynchronous: poll get_upload until it reports the import finished. Attachment urls usually expire, so import promptly rather than storing the link for later.

• delete_upload

  Permanently remove a media file from the library: its stored bytes and every file derived from it are deleted. Irreversible. An upload that never finished (no complete_upload after the PUT, an import that failed) is dropped too: nothing was stored. Refused, with nothing changed, while a playlist or a recent stream still uses it (IN_USE) — remove it from those playlists first with apply_playlist_operations — and for an image (UNSUPPORTED_TYPE). Requires confirm=true and the streamloop:destructive scope.

• get_billing_overview

  Use this to answer 'can this keep streaming, and for how long' — and whenever a stream fails to start or stops with no configuration problem, since check_stream_readiness deliberately does not look at credits. One call returns the credit balance, credits left, whether the account is in good standing, how fast credits are being spent right now, which streams are live and what they are costing, and the per-minute rate of each output quality (so a remaining-time estimate needs no second call). Read-only: buying credits is not possible from here, so if the balance is short, point the user at the Streamloop dashboard.

• get_streaming_usage

  Use this for questions about the past — 'how many hours did I stream last month', 'is my spend going up' — not about the present. Returns minutes streamed, credits spent and session counts bucketed over a period and split by output quality. get_billing_overview has the current balance and burn rate instead.

• get_account

  Who this token belongs to: the signed-in account's id, email, name, language and the default run-length new streams inherit. Use it to confirm which account an agent is acting for. It says nothing about which workspace is in use (get_selected_workspace) or about credits (get_billing_overview).

• list_workspaces

  Every workspace this account belongs to, with the account's role in each and which one is currently in use. Streams, media, playlists, destinations and credits all belong to ONE workspace and are never shared between them, so when a user says something exists and it is not in a list, check here before concluding it is missing — the answer is usually that another workspace is selected. Pass an `id` from here to select_workspace, or give the user the id to pin in their client configuration. `role` matters for workspace administration, which happens in the dashboard.

• select_workspace

  Switch which workspace this connection works in, for every later tool call on this connection (other connections, even ones sharing the same login, are unaffected). Takes an `id` from list_workspaces; membership is checked here and again by the API on every request, so this grants no access by itself. Use it when a stream, upload or destination the user describes is not in this workspace. Overrides a workspace the client pinned in its own configuration (the X-Workspace-Id header, or MCP_WORKSPACE_ID on stdio) for the rest of this connection. Call it again at any time to switch back.

• get_selected_workspace

  Which workspace this connection is working in right now, and where that came from: `explicit` (a select_workspace call), `header` or `env` (the client pinned it in its own configuration), or `token-hint` (the default the login carries). Call it when a result is unexpectedly empty, to confirm you are looking in the right workspace before telling the user something does not exist.

• scene_get

  Read the scene's draft (or a published version, with version): a resource (with its revision and children, the sub-paths to read next), a type such as element/Text or source/data (its props), a mask ending in /* (a list), or "" (the types). as: "image" on a frame or layer → a picture of it. (In a scene's draft; scene: its id.)

• scene_probe

  Fetch a URL once, changing nothing in the show: HTTP status, content type, an outline of the JSON (keys, their values, array lengths) or the page's title and text, and the rows a table would get from it with connector, pick and headers. Use it before creating a URL table, and to find the pick path or selector. (In a scene's draft; scene: its id.)

• scene_remove

  Delete whole resources (frames, layers, sources, components). All or nothing: anything in use by something not removed in the same call is refused, with what uses it. (In a scene's draft; scene: its id.) Removing a resource needs its revision in `revisions` (path → the revision you read; "*": whatever is there, on purpose); without it the answer is REVISION_REQUIRED.

• scene_set

  Create, replace or change one resource; get <type> shows what each takes, with an example. value is the whole resource, as get answers it: a frame { code: "<JSX>" } or, as JSON, { name, root }; a component { description, props, tsx }; a source or table its fields. edits change part of it: [{ old, new }] replaces text in its code (copy old from what get answers: code is stored formatted), or an object is merged into its fields. One layer changes alone at its own path: frame/<id>/<layer> with edits { props: { … } }. Every set is checked as the studio checks it; a refused set changes nothing: read the error, fix, send again. The answer has the path it is stored at, its new revision, what changed, and draftRevision (the draft as it is now: what publish takes). (In a scene's draft; scene: its id.) Changing a resource that exists needs its `revision`, from the answer that read it ("*" overwrites whatever is there, on purpose); without it the answer is REVISION_REQUIRED. A new path needs none

• list_scenes

  Lists the workspace's scenes, newest first: id, name, the version last published (0: never) and when. Read one's draft with scene_get (path "" lists what it holds).

• create_scene

  Creates a scene with an empty draft, nothing published. Build it with scene_set (frame/<id> for each frame, source/… for what it reads), then publish_scene. Each call creates another scene.

• publish_scene

  Publishes the draft exactly as it was at draftRevision (required) as the scene's next version: what streams playing it play from then on. All of it is checked first; a refusal (SCENE_INVALID) lists each problem — fix them with scene_set and publish again. Edits made after draftRevision are not published (the answer says so, stale: true). If someone published after the version your draft is based on, it is refused (STALE_PUBLISH: publishedVersion and what would be reverted) — read the draft again; only with the user's say-so send overwritePublished: <that version>. When that version is a revert (publishedVersionIsRevert), reading again changes nothing: overwritePublished, or discard_scene_draft to keep it.A scene on air is refused with CONFIRM_REQUIRED naming the streams — tell the user, then send confirm: true. An unchanged draft publishes nothing; dryRun checks it and lists what would change. The answer lists what changed, as resource paths.

• discard_scene_draft

  Puts the draft back to the published version: every change made since it was published is lost (nothing on air changes). draftRevision (required) is the draft you reviewed: if it changed after that, nothing is discarded (CONFLICT). dryRun: true lists what would be lost and discards nothing — show the user that first. Refused (NOT_PUBLISHED) when nothing is published.

• list_scene_versions

  Lists a scene's published versions, newest first: number, when, by whom. Read one with scene_get and version.

• revert_scene

  Publishes an earlier version's document as the next version (the versions in between stay; the draft is untouched — publishing the draft later is refused with STALE_PUBLISH until you send overwritePublished, and discard_scene_draft makes the draft this version too). expectedVersion (required) is the latest published version you saw (list_scene_versions, list_scenes): if someone published since, nothing changes (STALE_PUBLISH: publishedVersion and what the revert would also take off air). On air it is refused with CONFIRM_REQUIRED like a publish: tell the user, then send confirm: true.

• delete_scene

  Deletes the scene, its draft and every published version, for good. Refused (SCENE_IN_USE) while a stream plays it. Its ingest keys are revoked and its cameras removed.

• set_stream_scene

  Makes a stream play a scene (its published version) instead of a video playlist, or with scene null stops doing so. Refused (STREAM_LIVE) while the stream runs: stop it, set the scene, start it again. The scene must be published first (publish_scene).

• get_scene_state

  Answers each stream that plays it: the stream's state and, under onAir while it runs, the frame/<id> on air (frame) and the one cued next, the controls' values, each source's status and what its playlists play.

• control_scene

  Acts on the scene on air, as its operator would: goFrame (take frame/<target> to air, with a transition), next (cue frame/<target> so the take is instant; no target clears the cue), setControl (set one of its controls; scene_get control/* lists them), setData (replace a table's rows), skip (a playlist source to its next item). Viewers see it at once. The arguments are checked first, then against what is published (a frame, control, table or playlist source it doesn't have, a toggle given "yes": INVALID_INPUT); only then is it refused while nothing plays it (SCENE_OFFLINE). A SCENE_TIMEOUT may or may not have applied: send an actionId (a new uuid per action, kept by you) and retry with the SAME actionId and arguments — it is applied at most once. Without an actionId, never retry an action that isn't idempotent (skip, a button) blind: read get_scene_state first.

• create_scene_ingest_key

  Makes the key an encoder (OBS, vMix, a phone app) sends a live feed with, for one of the scene's rtmp or srt sources: RTMP, RTMPS and SRT URLs with the key, shown in this answer only — give them to the user. Make the source first (scene_set source/rtmp/<id>). The source's status is waiting until an encoder connects with this key, and live while it publishes. The key's own id (ingkey_…) is what revoke_scene_ingest_key takes.

• rename_scene

  Renames the scene (what the dashboard and list_scenes call it).

• list_scene_inputs

  Lists a scene's ingest keys (id ingkey_…, which source, live or not, never the key itself), its secrets (names only) and its IP cameras: what create_scene_ingest_key and set_scene_secret made.

• revoke_scene_ingest_key

  Revokes an ingest key: the encoder using it is cut off at once. A new key for the same source: create_scene_ingest_key.

• delete_scene_secret

  Deletes a saved secret: a table that names it ("$secret:<name>") stops getting it.

• set_scene_secret

  Saves an API key or token a table sends (sealed; never shown again). A table names it as "$secret:<name>" in a header value or a URL's query. Only a key the user gave you.