Orby Assistant API
Orby is Orbit’s in-dashboard operator assistant. These endpoints power the Orby chat panel: you send a message, Orby streams back a response over Server-Sent Events (SSE), and — when a turn proposes an action that changes data (such as sending an SMS or reassigning a conversation) — it pauses for an explicit approval before running it. Orby is operator-facing. Every endpoint runs in the context of the signed-in dashboard user, scoped to that user’s organization and tenant. There is no server-to-server API-key path for Orby. Base path:/api/v1/orby
Authentication
Orby uses the dashboard user (Bearer token) method, not an API key. Send the signed-in operator’s JWT:X-API-Key or as a dv_* Bearer token — is rejected with 403 ORBY_SESSION_REQUIRED. There is no server-to-server path.
Every Orby endpoint requires one of these operator roles: owner, admin, developer, viewer, or billing. Two knowledge-base maintenance endpoints (POST /kb/reindex and GET /kb/status) additionally require super-admin and return 403 INSUFFICIENT_PERMISSIONS otherwise.
A thread belongs to the operator who created it. You can only list, read, and post turns to your own threads — requesting another operator’s thread returns 404.
Rate limits
When you exceed the turn limit,
POST /assistant returns 429 ORBY_RATE_LIMITED with a Retry-After header (seconds).
Run a turn
POST /api/v1/orby/assistant
Start a new Orby conversation or continue an existing thread. The response is an SSE stream (Content-Type: text/event-stream), one event per token and per lifecycle step, terminated by a done event.
The operator’s message. 1–8000 characters.
Continue an existing thread. Omit to start a new one — the response stream reports the new
thread_id in the final response event, and the thread is auto-titled from your first message.Optional context describing the dashboard page the operator is on, so Orby can ground its answer. All fields are optional.
Idempotency-Key header to make a retried turn safe against double-execution of any tool it runs.
Stream events
Each SSE frame has anevent: name and a JSON data: payload. Read them in order until you receive done (success) or error (failure); the connection then closes.
When Orby pauses on a
tool_pending event, you can resume the same turn either by redeeming the pending action through the tool-actions endpoints, or by sending a follow-up turn on the same thread whose message is a plain confirm / yes / cancel. The chat reply and the explicit approve/reject button resolve through the same path, so the audit trail is identical.Threads
List threads
GET /api/v1/orby/threads
Return the operator’s most recent threads (up to 50, newest first) for the “Past chats” panel.
Create a thread
POST /api/v1/orby/threads
Pre-allocate an empty thread before the first message (the chat panel uses this to reserve a thread id up front). You can also let POST /assistant create the thread implicitly by omitting thread_id.
Optional thread title (max 200 chars). Left empty, the thread is auto-titled from the first message.
Optional page context stored on the thread.
Get thread messages
GET /api/v1/orby/threads/{id}/messages
Replay a thread’s persisted messages (oldest-first) to re-render history on reload.
Thread id.
Tool confirmations
When a turn proposes an action that changes data, Orby does not run it immediately. It emits atool_pending event carrying a pending_action_id and waits. Approve to execute, or reject to cancel. A pending action expires 5 minutes after it is created; an expired action returns 409 PENDING_ACTION_EXPIRED.
Approve an action
POST /api/v1/orby/tool-actions/{id}/approve
Execute the pending action. Returns the tool’s result once it runs.
The
pending_action_id from the tool_pending event.Reject an action
POST /api/v1/orby/tool-actions/{id}/reject
Cancel the pending action without running it.
The
pending_action_id.Poll an action
GET /api/v1/orby/tool-actions/{id}
Read the current state of a pending action, including its expires_at so you can render a countdown. A pending action whose window has elapsed is reported as cancelled with error_code: PENDING_ACTION_EXPIRED.
The
pending_action_id.Action states are
pending, executing, done, undone, failed, and cancelled. Only a pending action can be approved or rejected — acting on any other state returns 409 PENDING_ACTION_NOT_APPROVABLE, and a concurrent second approve returns 409 PENDING_ACTION_RACE. Both approve and reject are idempotent in effect: the action runs (or cancels) exactly once. A done action moves to undone when the operator reverses it within the tool’s undo window — for example, a sent message rolled back inside its 30-second grace period. Treat undone as a terminal state whose side effect has been undone; it differs from cancelled, which marks an action that was rejected (or expired) before it ever ran.Knowledge-base search
Orby can search the Orbit product documentation so operators can answer “where do I configure X” without leaving the dashboard. These endpoints sit under/api/v1/orby/kb.
Search docs
GET /api/v1/orby/kb/search
Hybrid search over the Orbit docs index. Available to any authenticated operator role.
Search text. 1–500 characters.
Results to return (max 50).
Restrict to a docs section.
Restrict to a docs category.
Find a setting
POST /api/v1/orby/kb/find-setting
Map a plain-language description to the dashboard route where the setting lives. Available to any authenticated operator role.
What the operator wants to configure. 1–500 characters.
Matches to return (max 20).
Reindex and status (super-admin)
POST /api/v1/orby/kb/reindex triggers a rebuild of the docs index and returns immediately with { "scheduled": true } (or { "ran_inline": true } when the corpus is available in-process). GET /api/v1/orby/kb/status returns a health snapshot: total and stale chunk counts, the last run timestamp, the current version, and cache hit rate. Both require the super-admin role and return 403 INSUFFICIENT_PERMISSIONS otherwise.