Skip to main content
Your agent is one artifact with many front doors. Deployment is a ladder: start with the zero-code widget and climb only as far as your needs require — browser access without a backend, backend-minted sessions, or a phone number. Every channel runs the same agent with the same configuration.
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.

​
Choose a channel

In increasing order of integration effort and control:

1. Embeddable widget

Drop a prebuilt call widget into your site — zero code.

2. Public agents

Browser-only: the SDK connects with just an agentId, gated by an origin allowlist and rate limits.

3. Authenticated sessions

Your backend mints a session token; the Web or React SDK takes it from there.

4. Phone

Bind a number and callers dial straight in — no client code at all.
Building a client on a stack the SDKs don’t cover? The wire protocol documents the wire-level session contract. 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.
Agents marked public skip the backend step entirely — the SDK connects with just an agentId, gated by an origin allowlist and rate limits.
For phone calls there is no client integration: assign a number, and inbound calls connect directly to your agent — which can transfer callers to another number mid-call. See Phone numbers.

​
Going further

Versions & publishing

The publish step every channel depends on.

Authentication

API keys, session tokens, and which one belongs where.

Conversation history

List sessions and read full transcripts over REST.

Wire protocol

The wire-level session contract, for building your own client.