​
Overview

Agent Stream is a WebSocket endpoint that lets a telephony provider point its media stream at a single URL and drive a EESI agent run. The agent UUID in the URL selects the agent, and the provider path segment selects the streaming protocol. Provider-specific identifiers come from the stream protocol itself. For Cloudonix, EESI reads the domain from the start.accountSid field, then uses the matching stored telephony configuration to validate the session and issue provider API calls (hangup, transfer) during the call. This is useful when:
  • You’re integrating EESI into a SIP gateway or in-house dialer that already speaks a supported provider’s streaming protocol
  • You want one stable endpoint per agent rather than wiring up an inbound webhook per phone number
Agent Stream currently supports the Cloudonix provider only. Other providers return NotImplementedError until a per-provider implementation lands. If you need Twilio, Plivo, Telnyx, Vonage, ARI, or another provider, please open a request on GitHub Discussions with your use case.

​
Endpoint

{provider} is the registered provider name, currently cloudonix. {agent_uuid} is the agent’s stable UUID (see Get the Agent UUID below). On self-hosted deployments, replace api.eesi.ai with your backend host.

​
Prerequisites

  • A EESI agent (workflow) — published or in draft is fine
  • A Cloudonix telephony configuration in your EESI organization whose domain_id matches the accountSid Cloudonix sends in the stream start message. EESI uses the bearer token from this configuration to validate the call session and to issue provider API calls (hangup, transfer).

​
Get the Agent UUID

The Agent UUID is the workflow’s stable identifier — it doesn’t change when versions are published. To find and copy it in the UI, see Agent UUID.

​
Connect to the WebSocket

​
Path parameters

​
Cloudonix example

Use this URL inside the CXML <Stream> your Cloudonix Voice Application returns when the call needs to be bridged to the EESI agent:
The first two messages on the socket should be Cloudonix’s standard connected and start events (Twilio-compatible framing). EESI extracts streamSid, callSid, session, accountSid, from, to, context, tracks, and mediaFormat from the start event payload. It validates the session against Cloudonix using the bearer token from the stored telephony configuration matched by accountSid, then begins streaming audio.

​
Workflow run lifecycle

When the WebSocket is accepted, EESI:
  1. Looks up the workflow by agent_uuid
  2. Runs a quota check against the workflow’s owning user
  3. Creates a new WorkflowRun (call_type=inbound, mode=cloudonix, name WR-AGS-XXXXXXXX)
  4. Transitions the run to running
  5. Reads and validates the Cloudonix start message, then stamps the from/to numbers on initial_context, stores session as call_id on gathered_context, and records accountSid under the run’s inbound_webhook log
  6. Starts the agent pipeline
The run is visible under the agent’s Runs tab as soon as it’s minted, just like an inbound or outbound call.

​
Close codes

​
Security notes

  • Treat the URL as a secret — the agent UUID itself authorizes the connection. Store and transmit it only over TLS, and avoid logging the raw URL in places where access is broader than your operations team.
  • No bearer tokens or provider secrets are passed in the URL. Provider credentials live in the stored telephony configuration (matched by start.accountSid for Cloudonix) and are used server-side by EESI to validate the session and issue provider API calls.