Passthru Applet

overview the passthru applet sends call and streaming metadata from voice applet flows to your server, especially useful when executing voicebot applet (bidirectional streaming) stream applet (unidirectional streaming) passthru sends additional stream specific parameters as query parameters, enriching standard passthru behaviour refer to the standard passthru documentation here working with passthru applet this guide is an extended version with additional parameters for streaming flows how it works passthru makes an http get request to your url, passing url encoded call and stream metadata example http get https //yourserver com/passthru handler? callsid=56b1234567abcdef89abcdef12345678& flow id=voicebot flow xyz123& direction=inbound& from=+918888000000& to=+912233344455& stream\[streamsid]=6f048d2e897a0d2d4029560f3f541947& stream\[status]=completed& stream\[duration]=28& stream\[recordingurl]=https //recordings exotel com/exotelrecordings/exotelt/6f048d2e897a0d2d4029560f3f541947 mp3& stream\[streamurl]=wss\ //stream customer com/media& stream\[disconnectedby]=bot your backend must parse url query parameters nested keys (e g , stream\[status]) json strings json format (raw query string) sometimes, all parameters are sent in a single json string under the stream key json stream={"streamsid" "62xxx ", "recordingurl" "https //recordings exotel com/ ", "status" "completed", "duration" "28", "streamurl" "ws\ //10 32 76 120 5007/media", "disconnectedby" "user"} ensure your backend deserialises this string correctly handling passthru responses passthru requests can be handled synchronously or asynchronously sync exotel will immediately pass the call details synchronously during the call flow execution it is possible only to make a binary decision using passthru 200 ok → option a 302 found → option b the person on call will wait until your url responds async exotel will asynchronously pass the call details without interrupting the call flow execution use this mode when you don’t want to dynamically change flow execution the user will not experience a delay streaming specific fields (flat format) parameter description stream\[streamsid] unique streaming session id stream\[status] status (completed, failed, cancelled) stream\[duration] stream duration (seconds) stream\[streamurl] websocket url for streaming stream\[recordingurl] url to recording (if enabled) stream\[disconnectedby] disconnector (user, bot, na) stream\[detailedstatus] present on failure (e g , streaming call throttled) stream\[error] error string (e g , network failure or ws rejection) note the above fields are added on top of standard passthru parameters throttling scenario concurrency limit breaches trigger stream\[status]=failed stream\[detailedstatus]=streaming call throttled implement retry or fallback strategies accordingly failure handling below are the most common failure and disconnection scenarios captured in the passthru payload test 1 call hung up during greeting expected capture who disconnected and status { "status" "cancelled", "disconnectedby" "user" } test 2 invalid websocket url expected failure metadata including error, stream url, and disconnector { "streamsid" "b68e46bca0fdexxxxx89643f6d81196d", "recordingurl" "https //recordings exotel com/exotelrecordings/exotelt/b68e46bca0fdexxxxx89643f6d81196d mp3", "status" "failed", "duration" "0", "streamurl" "ws\ //xx x xx xxx 50/media", "error" "3009 failed to establish ws conn dial tcp 10 1 76 120 50 connect connection refused", "disconnectedby" "na" } test 3 call cancelled after delay in streaming setup expected accurate cancellation reason and disconnection origin { "streamsid" "6f048d2e897a0dxxxxx9560f3f541947", "status" "cancelled", "disconnectedby" "user" } test 4 call disconnected by bot after successful conversation expected final stream status and session metadata { "streamsid" "f5dd49d7ac3xxxxx4b491ce948501947", "status" "completed", "duration" "29", "streamurl" "wss\ //e33e 54 251 51 3 xxxxx free app", "disconnectedby" "bot" } these structured outputs ensure consistent understanding of streaming lifecycle and failure context note disconnectedby values are standardized to user, bot, na passthru logs enriched with detailed error messages improve debugging and recovery mechanisms