> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Landing shells: what the SDK demo and conversation-operators shells actually do

> Orientation for two dashboard landing shells — the SDK Live Demo browser-softphone page and the Inbox conversation-operators console — so a developer reading the Developer hub knows which tile to click and what each shell is for.

# Landing shells: SDK demo vs conversation operators

Two dashboard pages show up in navigation as destinations but read as
one-line tiles on a hub: **SDK Live Demo** at `/developer/sdk-demo` and
**Conversation operators** at `/inbox/settings/conversation-operators`.
Both are real working surfaces, not placeholders — but neither expects a
first-time visitor to know that from the tile alone. This page says what
each shell offers, who it serves, and when to keep walking.

## Why two shells, two audiences

The Developer hub tile map ([Developer console map](/guides/developer-hub-consoles))
bubbles every `/developer/*` route into one grid. That is good for
inventory and bad for intent: a tile labeled "SDK Live Demo" does not
tell you whether it is a marketing demo, a diagnostics harness, or the
canonical code sample. The conversation-operators entry has the same
problem one hub over — it sits under **Inbox → Settings**, reads as an
admin preference, and is actually a working authoring surface for the
inbox text classifier.

**SDK Live Demo** exists for the *integration developer* answering "does
browser calling work end to end on this platform before I embed it?" It
places a real outbound call from the browser through the LiveKit voice
room — the same token-and-dial path the dashboard dialer and the Web
SDK `Softphone` use — billed to your org's wallet. One page, one job:
prove the browser-calling chain.

**Conversation operators** exists for the *operations owner* answering
"how do I teach the inbox what to flag?" It is a CRUD console for the
custom classifiers the inbox runs over every text thread — name,
instruction, output type, channel scope — capped at 25 active operators
per tenant. Clicking it expecting a product tour wastes your time;
clicking it to author a refund-intent signal is exactly right.

## The SDK demo surface

Open **Developer → SDK Live Demo** (`/developer/sdk-demo`). The rendered
page is deliberately thin: an optional **Caller ID** field, a required
**Destination** field, a **Call** button, and a status badge. Once a
call is live it adds a state readout, a mute toggle, and a DTMF dial
pad. Underneath, it fetches a short-lived LiveKit token via
`POST /voice/softphone/token` and dials via `/voice/softphone/dial` —
the same two calls the production softphone makes, so a green call here
means your network, browser permissions, and org wallet all pass.

Who it serves:

* **Proof before embed** — run one call in the dashboard before you ship
  the softphone in your own app, so the failure you are debugging is
  your code, not the chain.
* **Support reproduction** — when a customer report says "calls fail,"
  this page is the fastest same-account repro an engineer can run
  without touching the dialer UI.

Where it stops: the demo exercises *calling*, not the SDK's type
surface. If what you actually want is the method list, generics, and
per-platform install, leave this page and go to **SDKs & Libraries**
(`/developer/sdks`) — the [SDK catalogue guide](/guides/developer-sdks-catalog)
and the [Web SDK docs](/sdks/web) cover that surface. The demo is a live
wire check, not SDK documentation.

## TypeScript + React wiring — bootstrap example only

The page's real payload is the pattern, not the UI. The minimal wiring
a JavaScript-using shell needs is:

```tsx theme={null}
import { SoftphoneProvider, useSoftphone } from "@/lib/softphone/softphone-context";

// Mount the provider once at the app layout level — it owns the
// LiveKit room, the persistent remote-audio element, and DTMF wiring.
export function AppShell({ children }: { children: React.ReactNode }) {
  return <SoftphoneProvider>{children}</SoftphoneProvider>;
}

// In a component, dial through the context:
export function CallButton({ to }: { to: string }) {
  const { dial, hangUp, state } = useSoftphone();
  return (
    <button onClick={() => (state === "idle" ? dial(to) : hangUp())}>
      {state === "idle" ? "Call" : "Hang up"}
    </button>
  );
}
```

That is the whole contract: one provider at the root, one hook per
component, two calls (`POST /voice/softphone/token`,
`POST /voice/softphone/dial`). **Do not build on top of this snippet.**
It is enough to bootstrap a smoke test — anything beyond it (call
history, transfers, presence, agent state) belongs to the Web SDK and
the dialer, and hard-coding against this example past the bootstrap
stage will leave you re-implementing the SDK by hand. The full walk —
prerequisites, failure signatures, and what each status badge means —
is in [Test your browser calling setup with the SDK demo](/guides/sdk-demo-browser-softphone).

## Access and gating: who can open it, and why the hub won't feature it

The demo page is role-gated to **owner**, **admin**, and **developer**
because it places real outbound calls billed to the org's wallet —
viewer, billing, and agent roles cannot reach it. CORS is not the gate
(the dashboard is same-origin); the role gate and the wallet balance
are. If the tile is missing from your Developer hub, an org owner needs
to grant you one of those roles — and if the call stops at the guard
with `INSUFFICIENT_BALANCE`, the wallet needs a top-up before any demo
passes.

That gating is also why this page should **not** be promoted over the
Developer hub: a role-restricted, wallet-billing demo is a
behind-the-scenes sanity check, not a landing surface. The hub tiles it
at rank with twenty other consoles; this guide exists so a developer
who lands on the hub knows which tile to click, not to argue the tile
should be bigger. The conversation-operators console is gated harder
still — **owner** and **admin** only, matching the API's admin-role
gate on every operator write — for the same reason: it mutates tenant
taxonomy, it does not demo anything.

## Where to go from here

* [Developer console map](/guides/developer-hub-consoles) — the full
  tile inventory this page is a footnote to
* [Test your browser calling setup with the SDK demo](/guides/sdk-demo-browser-softphone)
  — the end-to-end walk of `/developer/sdk-demo`
* [SDK catalogue guide](/guides/developer-sdks-catalog) — the install
  and type surface the demo deliberately skips
* [Run the conversation-intelligence operator console](/guides/conversation-operators-console)
  — the operator lifecycle the Inbox settings shell exposes

Treat both shells as low-impact, high-specificity surfaces: they answer
one question each and are not the official guides. The official guides
are the targets to bookmark; the shells are the places you click once.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.