Skip to main content

AI assistants

An assistant is an Orbit AI agent: a named system prompt, model, and tool set that you bind to a channel when you deploy it. This page is the worked reference for the assistant lifecycle — create, list, fetch, update, deploy, undeploy, and delete — with one assistant_id carried across the whole sequence. Field-level reference lives in the Agents API; this page walks the sequence end to end. Base path: /api/v1/agents Authentication: API key (X-API-Key) or session JWT. Create, update, deploy, undeploy, and delete require an owner, admin, or developer role; list and fetch are open to any authenticated role. Every response below carries the full { data, meta } envelope — meta.request_id and meta.timestamp on the success path, a labelled error envelope on the failure path — the same floor as SDK sample coverage policy.

Lifecycle worked sequence

Create the assistant once, reuse its assistant_id for everything afterward. Nothing seeds channel binding on create — the agent lands as a draft, and deploy flips it active.

1. Create the assistant

Response 201:
Carry the returned assistant_id (agt_8f2e41abcc9d70) through the rest of this page — it is the same id you pass to fetch, update, deploy, undeploy, and delete.

2. Deploy the assistant to a channel

deploy binds a channel and moves the assistant out of draft into active. The channel name is one of webhook, sms, whatsapp, voice, or rcs; webhook_url is required only for webhook channels, and a phone_number is required only for SMS / WhatsApp / voice.
Response 200status is active and config.deployment carries the channel binding:

3. List to confirm the assistant is live

Response 200 — the envelope’s meta.pagination carries the cursor and has_more pair you use to walk the full list:

4. Fetch one assistant by id

Same envelope as the list, without pagination. Use this form when you already know the id — there is no separate “assistant detail” resource.

5. Update the system prompt, tools, or safety config in place

PATCH rewrites only the fields you send. Bump the prompt or safety configuration without redeploying.
Response 200:

6. Undeploy, then delete

undeploy drops the channel binding and flips status back to draft. Delete the assistant only when it is no longer needed — conversation history stays on the tenant.
Undeploy returns 200 with the same envelope. Delete returns 204 No Content with an empty body.

Error envelopes

An unknown id — whether passed to fetch, update, deploy, undeploy, or delete — answers 404 with a labelled error envelope, not a bare status:
404 Error
Validation failures on create come back as 422 VALIDATION_ERROR — one entry per field, with the same meta block. A cross-tenant id returns the same 404 NOT_FOUND as one that never existed, so existence cannot be probed across organizations. If you receive a 403 INSUFFICIENT_PERMISSIONS, the caller’s role is below developer; only owner, admin, and developer may write assistants.

Escape hatches beyond the Node.js and Python samples

Every public SDK ships an untyped request method that reaches any endpoint when a typed helper does not exist yet — the same semantics as the Agents API page’s Python escape hatch. The per-language idiom:
  • Go — plain net/http; set X-API-Key + Content-Type and decode the { data, meta } envelope directly.
  • RubyNet::HTTP over the host + path pair; JSON.parse the envelope.
  • PHP — cURL with json_encode bodies; json_decode returns the envelope as an associative array.
  • Java / C#client.RequestAsync / client.request per the SDK language policy’s escape-hatch table; the route shape above applies verbatim.
See also Agents API for the full field catalogue and Agent templates for the pre-built-into-assistant flow.