Skip to main content
Agent routes are available to Admin, Manager, and Agent API keys. Creating or editing an agent changes workspace configuration. Publishing an agent changes live inbound routing.

Endpoint summary

List agents

GET /agents Query parameters are page, limit, search, sortBy, sortOrder, and status. Status is draft, active, or archived.
Response: 200 with the standard { data, meta } envelope. Each item contains the agent configuration and a publication object when it has published phone-number bindings.

Create an agent

POST /agents The smallest request supplies a name, instructions, and optionally a description. When pipelineConfig, memory, and operational settings are omitted, the service applies platform defaults. Discover currently enabled provider and model identifiers from the /agents/options/* routes before sending a custom pipeline.
Validation:
  • name: 1–128 characters;
  • description: optional, up to 2,000 characters;
  • instructions: 1–10,000 characters;
  • metadata: optional JSON object.
Selected fields from a 201 response:
Provider defaults and returned configuration can change with workspace enablement; treat the response as authoritative.

Retrieve or update an agent

GET /agents/:id returns the complete agent object. PATCH /agents/:id accepts the same configurable fields as creation; omitted fields stay unchanged.
Response: 200 with the updated agent. Common failures are 400 for invalid configuration and 404 for an unknown or cross-workspace ID.

Read model and voice options

Use these read-only endpoints before constructing a custom pipelineConfig:
Each option response is an array or provider-grouped catalog describing identifiers, labels, supported languages, voices, and capabilities for that modality. The voice route returns 404 when the provider/model pair has no curated voice set. Treat the live response as the schema authority and tolerate additive capability fields.

Test with a text message

POST /agents/:id/test
Selected fields from a 201 response:
The message must contain 1–10,000 characters. This is a text playground call; it does not place a phone call. It can invoke paid model providers and can expose submitted text to configured processors.

Publish an agent for inbound calls

POST /agents/:id/publish Publishing reconciles the agent to the exact non-empty set of phone-number IDs in didIds. First call GET /agents/:id/available-dids to obtain eligible IDs.
The 201 response is the agent object with publication details:
Publication changes production inbound routing. The current publish path creates new agent bindings with call recording enabled by default, and this request has no recording override. An inbound call can create a conversation, invoke AI and voice providers, consume credits, and create a recording. Confirm recording notices, consent, retention, and disclosure rules with Gomobile before publishing.
POST /agents/:id/unpublish takes no request body and disables all of the agent’s inbound bindings. Archiving or deleting also disables its bindings. Restoring does not reclaim a number automatically.

Lifecycle and deletion requests

The lifecycle POST endpoints take no request body and return 201 with the updated agent:
Archiving or deleting can be blocked while an active campaign uses the agent. Resolve that dependency before retrying. Invalid state changes return 409. DELETE /agents/:id soft-deletes the agent and disables its inbound bindings:
Use GET /agents/:id to retrieve one agent. Use the following paginated read to discover numbers that are unclaimed or already published to this agent:

Current limitations

  • Tools, policies, and preview experiences can be unavailable or incomplete in the current UI.
  • Knowledge-base attachment depends on agent pipeline compatibility; realtime agents do not currently expose the Knowledge Base tab in the current UI.
  • Do not automate provider/model IDs as permanent constants. Read the option endpoints and handle removal or workspace-specific availability.
All examples require X-API-Key. All IDs are UUIDs. See API basics for common errors and safe testing.

Pagination and request retries

Page-based lists use page=1 and limit=20 by default, with a maximum limit of 100, unless the endpoint above specifies an exception. Follow the response’s pagination metadata. See pagination for the response envelope. If a request returns 429, wait for Retry-After when supplied before retrying. For a mutation that times out, check the resource or run before repeating the request; repeating it can duplicate work. See errors for authentication and validation failures.