Channels

A channel is where people reach an agent — a web widget, WhatsApp, email, Telegram, Teams, Slack, SMS or the Workspace.

Channels are the human side of integration. Each channel adapter maps identity, formatting and human handoff for its medium, then opens the same kind of run an operator would open in the Workspace — so the agent, its tools, its approvals and its trail are identical whatever the entry point. The web widget uses a publishable embed key with an origin allow-list and optional signed identity; provider channels use the provider's official API and show an awaiting first event state until the first message arrives.

Channel kinds

The status column is deliberate. Available now means you can connect it today with nothing but the console. Available with your provider credentials means the adapter is present and works once you supply the provider account (your Slack app, your Azure Bot registration, your SMS or telephony provider) — without them the channel is honestly unavailable. Unofficial means a path the provider does not sanction; it is labelled, not hidden.

Next (roadmap): Teams, Slack, SMS and Voice without customer-provided provider credentials — a hosted provider account owned by Agentic Workforce ME. Until then those four rows read “available with your provider credentials” everywhere: console, website, this portal.

Web: the widget or the chat endpoint

Two web channels exist and they are not the same thing. The web widget is the recommended path for a public site or an app: a publishable embed key (hive_pk_…) bound to one agent, an origin allow-list, optional signed identity, and a browser talking to /v1/embed/* with nothing secret in the page. The web chat endpoint is the earlier platform='web' channel: conversations land in the console Inbox, where a person can take over. Both open the same kind of run.

WhatsApp

Media in, spoken replies out

On both paths an inbound voice note is transcribed before the run starts (the transcript becomes the user turn; the ledger keeps the audio reference and a transcription_status), and inbound images and PDFs reach the agent as attachments for a vision-capable model — up to 20 MB per file, PDFs rasterized per page. This includes the linked-device (QR) path, so a citizen can send a passport photo or a scanned form from a personal number.

Replies are text unless you opt in: set voice_replies: true in the channel config (PATCH /v1/channels/:id; existing keys are preserved). With text-to-speech configured on the platform, the governed answer is shortened for speech, synthesized and sent as a WhatsApp voice note — on the Cloud API path for every reply, on the linked-device path only when the person spoke first, as a push-to-talk note when the output format is Ogg/Opus and as a regular audio message otherwise. If synthesis or the send fails, the full text answer is sent instead; the conversation ledger records the outcome as a voice_reply or voice_fallback attachment with the failure reason (never the content). Text in stays text out.

These are deployment settings owned by the platform operator, not per-tenant API fields — ask for them when you plan a voice-first WhatsApp agent. An agent can also carry its own voice: manifest voice.tts (schema 2.17 — a voice id plus optional provider, model, language and voice settings). Its spoken replies use it when that provider (default VOICE_PROVIDER) is the deployment’s configured speech provider and a model is known (its own or VOICE_TTS_MODEL); otherwise the platform voice speaks. Everything else about the channel (readiness check, first-event badge, handoff) is unchanged.

The same run, whatever the door

• Identity. Each adapter maps the medium’s identity (a phone number, an email address, a chat user id, a signed widget identity) onto the conversation’s end user, so memory and permissions follow the person, not the medium.
• Formatting and handoff. The adapter renders the agent’s output for its medium and, where the medium supports it, routes a handoff to a person in Inbox.
• One run model. A message on any channel opens the same kind of run an operator opens in the Workspace: the same published agent, the same granted tools, the same approval policies, the same run steps and audit trail.
• Awaiting first event. A provider channel that is configured but has not yet received its first callback shows Awaiting first event (awaiting_first_event) rather than a false green; the badge flips on the first inbound message. POST /v1/channels/:id/test runs the readiness check before that.

API mapping

Every /v1/channels path takes an API key plus X-Tenant-Id and needs the admin role — listing, creating, changing and testing alike (an API key acts as admin; a console session needs it explicitly). The public message endpoints under /channels/:token/… take no API key: the channel’s public_key in the X-Hive-Public-Key header instead.

The embed surface (/v1/embed/*, the widget’s own API) is fully documented under REST API and JavaScript API. Channel provider secrets are write-only: they are stored encrypted, never returned, and used only by the adapter.