- Where users meet your agent: a prebuilt widget, your own UI built on the SDKs, a phone number, or a custom client.
- Who may start sessions: anyone visiting your pages, or only clients your backend has vouched for.
Publishing gates every channel: sessions always run the agent’s published
configuration, and creating a session against an agent that has never been
published fails. Publish before wiring
up any channel.
Where users meet your agent
In increasing order of integration effort:Widget
Drop a prebuilt call widget into your site: two lines of HTML, zero build
step.
Phone
Bind a number and callers dial straight in.
Custom client
On a stack the SDKs don’t cover, implement the wire
protocol directly.
Who may start sessions
The widget and the SDKs each work with either access mode; pick per agent. Phone numbers skip this decision entirely: inbound calls connect through telephony, not a browser session.Public agents
The client connects with just an
agentId: no backend, gated by an origin
allowlist and rate limits.Authenticated sessions
Your backend creates a short-lived session token with your API key: trusted
attribution and full control.
Still deciding?
How a browser session starts
For private agents, your backend creates the session. Your API key never ships to the browser. The browser SDK takes the resulting session token and handles audio and transport from there.Your backend
Your frontend
Going further
Versions & publishing
The publish step every channel depends on.
Authenticated sessions
The full session-creation reference: request fields, token lifetime,
errors.
Conversation history
List sessions and read full transcripts over REST.
Wire protocol
The wire-level session contract, for building your own client.

