Assistants

Creating, configuring and publishing an assistant for a merchant.

GET|POST      /api/v1/partner/tenants/{ref}/assistants/
GET|PATCH     /api/v1/partner/tenants/{ref}/assistants/{id}/
POST          /api/v1/partner/tenants/{ref}/assistants/{id}/activate/

Configuration

The fields you will actually set:

Field	Notes
display_name	The name the customer sees
agent_type	sales, support, booking, lead_qualification, custom
tone	professional, friendly, conversational, formal, casual
languages	e.g. ["en", "hi", "ml"]. Replies follow the customer by default
channels	["website"] today
instructions	The conversation script — how it greets, asks and closes
opening_message	First line of a conversation
capabilities	Feature switches, e.g. {"tool_servers": {"enabled": true}}
data_collection_fields	What to collect before the conversation ends
handoff	When and where to hand to a human

The system prompt is recompiled on every write — you never manage it directly, and it cannot go stale.

Enable the tool_servers capability or the tools you registered are silently ignored. This is the single most common thing to miss.

Going live is a separate call

A new assistant is created in preview. It is fully configured and answers nothing.

POST /api/v1/partner/tenants/{ref}/assistants/{id}/activate/

Only one assistant is live per business at a time; activating one stands the previous one down.

PATCH will never flip an assistant live, and never takes a live one down. Publishing is always this explicit call — so an unrelated config edit cannot silently change who is answering your merchant’s customers.

A sensible provisioning default

If you have the merchant’s category and a sentence about what they sell, you can produce a usable assistant with no questions asked. If you do not, one screen asking for tone and a one-line description is enough — the knowledge you already synced does the rest of the work.