- 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 — no client code at all.
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.

