The same widget as the first page, with nothing configured ahead
of time: the agent is typed into the form, and so is every dynamic variable —
+ Variable adds a key/value row. Useful for trying an agent whose variables
are not in example/scenarios/, or not known yet.
On top of that, an mp3 or wav file stands in for the microphone: pick a file,
press Call, and Play file pushes the recording into the live call.
The agent hears the file and nothing else — no microphone is opened. Useful for
replaying the same utterance while you change the flow: ASR, barge-in and the
answer all run on identical audio. The page swaps
navigator.mediaDevices.getUserMedia for a Web Audio bus; the SDK
knows nothing about it.
Because the page brings its own agent, the server sends the typed keys through as they are instead of filtering them against a scenario. That is a demo choice, not a template: a production backend still owes the guarantee the other two pages show — the browser names values, never the contract.
Used for the call instead of CFLOW_API_KEY, so one deployment demos any
organisation without an .env edit and a restart. It sits in the page
rather than in the widget because it is not a call parameter — it is which
organisation the call runs as. A key typed here also drops the scenario allowlist,
the same way naming another agent does.
POST /v1/calls/web — the browser gets back just the session JSON, and the
key in .env never leaves the server. The audio file is decoded in the
browser and never uploaded — only the WebRTC audio leaves, as a microphone's would.