This reference is generated from that document, so it matches the running service rather than a
copy kept beside it. Every page names the scope a key needs and the endpoint’s per-minute rate
limit, both of which come from the spec.
Where to start
Workspace
One call that reports what exists and suggests a next action. Start here rather than guessing
at the shape of an empty account.
Provision an agent
Settings, rules, functions and knowledge in a single atomic call.
Read real conversations
What customers asked and how the agent answered — read these before changing an agent, and
after, to check the change held.
Close the loop
Record what the agent should have said. An eval becomes a regression case rather than a note.
Your first call
Orientation before anything else —workspace reports what exists and what to do next, so you
are not guessing at the shape of an account you have not seen.
cURL
cURL
The build → verify loop
The API is shaped around one cycle, and the endpoints are most useful in this order:- Orient —
GET /workspacereports what is configured and what is missing. - Build —
POST /agents/provision, or the individual rule, function and knowledge endpoints. - Verify —
POST /agents/{id}/evals/runreplays the suite against a change. - Observe —
GET /conversationsandGET /analytics/agentsshow what happened in production. - Correct —
POST /evalsrecords the reply that should have been sent, which feeds step 3.
Scopes
Every endpoint declares the scope its key must carry. Across the 38:Related
- ResponseCX MCP server — the same surface as agent tools
- StateSet ResponseCX — what the product does