Integration overview

A worker runs a live conversation. In a meeting it does that as a named participant. On your own site it does the same thing in the browser: a visitor clicks, talks, and the worker answers, runs its brief, and hands back a structured outcome. This section covers the two supported ways to build that in, and what each one asks of you.

What a session is

Everything here is browser-based. A session is three things running together, and the SDK manages all three:

• a WebSocket to our relay, which carries the conversation in both directions;
• microphone capture from the visitor;
• audio playback of the worker, including interruption when the visitor talks over it.

Your page never holds a model credential and never talks to a model directly. It holds an embed key, opens a session, and reacts to what the session reports. Everything about how the worker behaves — its brief, its voice, its tools — is configured in the console, not in your code.

Two paths

Both paths use the same embed key, the same worker configuration, the same tools, and the same origin enforcement. Starting with the widget and moving to the SDK later does not mean rebuilding the worker — only the interface in front of it changes.

Path A — Embed widget

The fastest path, and the one most sites should take first. In the console, open your worker and go to Embed. The console generates a script tag carrying your embed key; paste it into your page before the closing </body> tag and deploy. The widget adds a launcher, asks for microphone permission when the visitor starts, shows call state while the conversation runs, and offers mute and end.

Take this path when:

• you want a worker live on the page today;
• our interface is close enough to what you would have built;
• the conversation is the whole feature — nothing else on the page needs to react to it.

Path B — Headless SDK

The SDK ships no interface at all. You import DWVoiceSession from https://app.delegateworker.com/sdk/v1/dw-voice.js, start a session with your embed key, and render whatever you want from the status and transcript events it gives you. Client tools let the worker call back into your page mid conversation, so the interface can change while it talks.

Take this path when:

• the worker is part of your product, not a widget bolted onto it;
• the conversation needs to drive your interface — filling a form, opening a record, moving a dashboard;
• you have design or accessibility requirements our widget does not meet.

Start at the headless SDK quickstart — it goes from an empty page to a working session with one client tool.

Before you start

Either path needs the same three things:

1. An account in the console at app.delegateworker.com.
2. A worker with a brief — what it is there to do, what it asks, what it hands back.
3. An embed key, with every domain you will run it on listed as an allowed domain. The key is published in your page source; the allowed-domains list is what makes that safe, and the browser origin is checked on our side for every session. See origin security.

What to keep human

A worker is a good fit for the conversation that repeats — the same intake, the same qualification, the same check-in, run the same way every time. It is not a fit for the conversation where the relationship is the point: the escalation, the negotiation, the bad news. Build the worker into the repeatable path and route the rest to a person. That routing is itself a tool call, and it belongs in the brief from day one.

Next

• Headless SDK quickstart — install, start a session, handle a client tool, end cleanly.
• Tools guide — webhook tools, tools that run in your page, and the act-then-react pattern for interactive onboarding.
• Session lifecycle and events — status values, transcripts, feedback, and end behaviour.
• Zoom documentation — running the same worker in meetings.