AgentConfig (instructions, voice, tools, and more). You edit a draft version, publish it, then assign it to phone numbers or expose it as a SIP endpoint.
All endpoints live under the /core prefix. Pass your credential in the Authorization header on every request; a personal access token (pat_) also requires the X-Anyreach-Org header. See Authentication. For the product concepts behind these endpoints, see Agents.
Scopes
Read endpoints accept either
agents:read or agents:manage. Every write, publish, and deploy endpoint requires agents:manage.
Agents
Versions
A version’s config is immutable once published — published versions reject updates. Create a new version (optionally frombase_version) to make further changes.
Publish a version
POST /core/agents/{id}/versions/{version}/publish marks the version published and, optionally, deploys it to phone numbers. The response is the list of affected phone numbers.
Publishing is blocked while instructions are generating, and blocked when instructions are stale (dirty and not manually edited) — regenerate first.
Drop the
X-Anyreach-Org header when using an organization API key (ak_) — it carries its organization implicitly.SIP deployment
Expose an agent over SIP atsip:<agent-id>@<your-sip-uri>. The agent must have at least one published version first.
Scaffolding agents
These endpoints kick off background workflows that build an agent for you. Each returns202 with a workflow_id.
The config contract
AgentConfig is the full shape of a version’s config. The authoritative contract is published as JSON Schema:
Use this endpoint to validate a
config before sending it to POST /core/agents/{id}/versions or PUT /core/agents/{id}/versions/{version}, rather than hard-coding field names.
Agents
What agents, versions, and publishing mean in the product.
Authentication
Credentials, the
X-Anyreach-Org header, and scopes.
