Skip to main content
POST
Start audio stream
This endpoint starts a new audio stream on a call that is currently in progress. Vobiz opens a WebSocket connection to the URL you provide and begins forwarding audio frames in near real time. You can start multiple concurrent streams on the same call - each one returns its own stream_id.
REST POST .../Stream/ vs the <Stream> XML verb
  • Use REST to attach a stream to a call that is already live - for example, to start transcription after a transfer, or fork a second pipeline mid-call. It returns a stream_id you can later list, retrieve, or stop.
  • Use the <Stream> XML verb when your answer handler is setting up the call from the start. The XML verb is the path for full-duplex AI voice agents.
Both share the same WebSocket event protocol once connected (start, media, playAudio, checkpoint, clearAudio, stop). See Stream Events Overview.
Authentication required:
  • X-Auth-ID - Your account Auth ID
  • X-Auth-Token - Your account Auth Token
  • Content-Type: application/json
Important: The target WebSocket URL must be reachable from Vobiz and must accept connections over wss:// in production.
On this REST route, bidirectional must be the string "true". A JSON boolean true is accepted and silently produces a one-way stream - no error, no warning, and your playAudio events are discarded. The <Stream> XML verb accepts either form; this route does not.
Attaching to a leg that is in a conference. This route is the way to stream from a call that is also in a <Conference> - XML verbs execute in sequence and a bidirectional <Stream> holds its leg, so a <Conference> placed after it is never reached. The REST route attaches the stream as a media bug on the channel, outside XML sequencing.Wait for the ConferenceEnter callback and allow roughly two seconds before attaching. The leg has to settle in the room first, or the stream receives no audio.

Path parameters

Request Parameters

Choose the inbound content_type that your speech or media processor accepts. L16 carries raw 16-bit PCM; μ-law uses less bandwidth at 8 kHz.

Status Callback Events

When the stream changes state, Vobiz sends a form-encoded HTTP request to your status_callback_url. The Event field is one of: These HTTP callbacks are a separate channel from the WebSocket events. For the exact payload fields and examples, see Status callback events.
The authoritative “call is over” signal across all termination paths (caller hangup, carrier drop, timeout, server stop) is the Event=Hangup POST to your call’s hangup_url, not StopStream. See Detecting end of stream.

Bidirectional streaming

When bidirectional=true, your WebSocket server can send outbound playback audio to the call. This format is independent of the inbound REST content_type.
Send audio from WebSocket to call
For the full bidirectional protocol - checkpoint, clearAudio (barge-in), stop, and the inbound media/start events - see Stream Events Overview and Play Audio Event.
Do not set REST content_type to L16/24 kHz to play a 24 kHz TTS response. content_type configures inbound Vobiz-to-application audio. Set sampleRate: 24000 on a playAudio event that contains genuine L16/24 kHz audio.

Response

Returns a confirmation along with the generated stream_id.
Response - 202 Accepted

Example Request

cURL

Authorizations

X-Auth-ID
string
header
required

Your Vobiz account Auth ID

X-Auth-Token
string
header
required

Your Vobiz account Auth Token

Path Parameters

auth_id
string
required

Your account Auth ID

Example:

"MA_XXXXXX"

call_uuid
string
required

Body

application/json
service_url
string
required
Example:

"wss://your-server.com/ws"

bidirectional
boolean
default:false
audio_track
enum<string>
default:both
Available options:
inbound,
outbound,
both
audio_format
enum<string>
default:mulaw
Available options:
pcm,
mulaw

Response

200 - application/json

Stream started