Connect Applet for Agent handover

connect applet configuration, dynamic url, and escalation via passthru for agent handover overview you can configure the connect applet's parameters in one of two ways flow builder — set parameters directly in the applet's ui dynamic url — control parameters at runtime via your own application endpoint regardless of which method you choose, you must still configure the transitions (which applet runs next) while building the flow if you configure parameters dynamically, you set a primary url , which handles the requests an optional fallback url , contacted if something goes wrong with the primary url request (exotel → your application) if an application url is set for the connect applet, exotel makes a get request to that url with call details as url encoded http query parameters only some parameters may be passed, depending on where the connect applet sits in the flow header header description exotel version version of connect applet parameters against which your endpoint's response will be validated current version 1 0 query parameters parameter description callsid unique identifier of the call callfrom outgoing call number the call is made from incoming call number the call is received from callto outgoing call number being dialed out incoming call number where the call landed direction incoming or outbound dial created timestamp when the call is created (yyyy mm dd hh\ mm\ ss) dialcallduration seconds from when the call is triggered to when the second leg ends (including conversation time) can be 0 depending on the previous applet and if there's no second leg starttime timestamp when the call started (yyyy mm dd hh\ mm\ ss) endtime constant value 1970 01 01 05 30 00 (unix epoch) use the call details api a few minutes after the call ends to get accurate end time calltype see table below dialwhomnumber number of the agent who was dialed last flow id flow id associated with the call from incoming call caller's number outgoing call number of the first leg to incoming call the exophone the call came into outgoing call the number dialed currenttime current server time (yyyy mm dd hh\ mm\ ss) calltype values scenario value ivr only, no connect applet call attempt call conversation happened completed client hung up during connect applet client hangup connect applet, no agent picked up incomplete went to voicemail applet voicemail conditional parameters passed only if certain conditions are met parameter description dialcallstatus what happened on the second leg if the previous applet was "connect" values completed, busy, no answer, failed, canceled digits passed if a gather or ivr applet preceded this one; equals the digits entered note comes wrapped in double quotes (") — trim them to get the actual digits customfield if the call was initiated via api, the value passed as customfield in that api call recordingurl populated if the previous applet was "voicemail"; contains the voicemail recording url there may be a delay before it's accessible, depending on recording length response (your application → exotel) this is what exotel expects back from your get request it decides how connect executes during the call response header content type application/json sample response { "fetch after attempt" false, "destination" { "numbers" \["+919812345678"] }, "outgoing phone number" "+918047115777", "record" true, "recording channels" "dual", "max ringing duration" 45, "max conversation duration" 3600, "music on hold" { "type" "operator tone" }, "start call playback" { "playback to" "both", "type" "text", "value" "this text would be spoken out to the callee" } } response parameters parameter mandatory/optional description fetch after attempt optional; default false whether to re fetch parameters (including destination numbers) after each unsuccessful dial attempt false dial happens based on the initial response only, no subsequent hits to the url true connect re fetches parameters (hits the url again) if a dial attempt fails if two consecutive fetches return the exact same destination numbers, exotel will not retry further even if this is true re fetch request includes standard params plus \<connect> params from previous dial attempts; response format is the same as above destination mandatory the destination(s) to dial see sub parameters below destination numbers — array of e 164 format numbers to dial, in the order they appear example "destination" {"numbers" \["+622131921111", "+622131921112"]} destination trunk — route the call to a sip trunk instead of a number, e g "destination" {"trunk" "trunk 2134"} used for sip transfer to agents/contact centers (see escalation via passthru applet below) outgoing phone number optional; default = incoming exophone exophone to dial out from (e 164 format) must exist in your account subject to telecom circle/region restrictions (e g , outgoing exophone in delhi can't be used if the incoming exophone is in bangalore) both legs' exophones can be on the same server if the exophone isn't in your account or fails validation, exotel falls back to using the same exophone as the first leg consult exotel support before using this record optional; default false whether to record the call recording channels optional; default single single or dual (caller and callee in separate channels) max ringing duration optional; default 30 ringing duration limit, in seconds can be increased up to 60 max conversation duration optional; default 900 (15 min) conversation duration limit, in seconds can be increased up to 4500 (75 min) music on hold optional; default default tone default tone (exotel's default), operator tone (audio returned by the operator on the dialing channel as is), or custom tone (audio url provided in the response) example {"type" "custom tone", "value" "\<audio url>"} parallel ringing optional dial all destination numbers simultaneously {"activate" true, "max parallel attempts" 5} max parallel attempts range 1–10, default 5 chargeable feature — confirm with your account manager or hello\@exotel in before use dial passthru event url optional url requested for dial start and dial end events start call playback optional play a recording or tts to the called number playback to both or callee type audio url or text example {"playback to" "both", "type" "text", "value" "hello, this is a sample text"} audio file requirements 8 khz sample rate, 16 bit depth, 128 kbps bit rate, mono channel, wav format if reusing the same audio url filename, it will be cached by exotel servers — use dynamic filenames if the audio content changes each time custom params optional custom sip headers passed with a trunk routed call, e g "custom params" "param1=value1\&param2=value2" up to 3 custom headers, max 200 bytes total headers prefixed with exotel or veeno are platform reserved all of the above can also be set via the dashboard if you configure the connect applet through the flow builder instead of a dynamic url fallback url triggers the fallback url is called when the primary url doesn't return http 200 ok the primary url doesn't respond within the timeout period (5 seconds) the primary url returns an invalid response content type is not application/json mandatory parameters are missing audio url / text isn't a valid http/https url returning 200 transition to next applet set these transitions in the flow builder to decide what runs next scenario behavior after the call conversation ends triggered if a conversation occurred if nobody answers triggered if the number was dialed but no conversation occurred falls back to "we didn't dial anyone" if not set we didn't dial anyone triggered if no dial occurred at all, including both primary and fallback urls timed out or returned a non 2xx response; both urls returned an invalid payload; the returned number was in an invalid format; or an empty destination was returned notify or escalate via passthru applet use the passthru applet to notify your contact center or escalate a call to an agent two modes are supported notification mode — the bot triggers a webhook via the passthru applet transfer mode — the bot requests a sip transfer to hand the call to an agent, by creating a trunk in exotel and routing the connect applet's destination to it (using destination trunk, above) setting up sip transfer follow the sip trunking api reference to create a trunk for inbound calls create a flow using the connect applet in app bazaar in the dial whom field, use sip \<trunkid> for custom routing, use a dynamic url to fetch the destination uri and pass headers, as described above up to 5 custom sip headers are supported (e g x param1=value1, max 4000 bytes total) headers prefixed with exotel or veeno are reserved by the platform connect applet — dynamic url response example for sip transfer { "fetch after attempt" false, "destination" { "trunk" "trunk 2134" }, "custom params" "param1=value1\&param2=value2", "record" true, "recording channels" "dual" } references programmable connect working with connect applet (dynamic url) docid\ ey4pwuojakmxmczuxndis passthru applet docid 4w7wvq3jabjqpwtfyab8