A Complete Guide to the API
A practical walkthrough of the Contro1 runtime API: which endpoint an agent calls, when to call it, what to send, and how approvals, audit records, traces, and evidence fit together.
Core API
A compact map of the public Contro1 runtime API: request creation, Control Map preview, audit records, and thread timelines.
Use this page when you want the simple list of public runtime API calls that agents and framework connectors should call directly.
These are the calls production agents and framework connectors normally use. Base URL: https://api.contro1.com/api/centcom/v1.
| Method | Endpoint | Use it for |
|---|---|---|
| POST | /requests/control-map | Optionally preview role mappings, fallback reviewers, on-shift capacity, and approval-policy satisfiability for complex routing. |
| POST | /requests | Create a human approval, yes/no, free-text, review, or decision request. |
| GET | /requests?thread_id=... | List requests in one thread for connector and case reconstruction workflows. |
| GET | /requests/:id | Fetch request state, response, operator details, policy context, and protocol response. |
| GET | /requests/:id/evidence | Export one JSON evidence packet with request metadata, policy context, reviewer decision, webhook status, timestamps, and final protocol response. |
| DELETE | /requests/:id | Cancel a pending request before an operator has completed it. |
| POST | /audit-records | Record an autonomous action that should be audited without pausing for human approval. |
| GET | /audit-records | Search audit records by actor, source, workflow, outcome, severity, correlation_id, external_request_id, thread_id, tags, text, or date range. |
| GET | /audit-records/:id | Fetch one audit record. |
| GET | /threads/:thread_id | Fetch the combined timeline for a thread across requests and audit records. |
| GET | /agents | List the agents that have called Contro1, with verification status and least-agency scopes. |
| GET | /agents/:agent_id | Fetch one agent: identity, verification, scopes, and status. |
| GET | /agents/:agent_id/trail | Full decision trail for one agent (add ?trace_id= to scope to one run). |
| GET | /agents/:agent_id/evidence | Signed evidence bundle for one agent (add ?format=csv for a spreadsheet). |
| GET | /traces/:trace_id | Full execution trace for one run: span tree, sub-agents, and tool calls. |
If your agent runtime is Python, Node, or TypeScript, use the official SDKs instead of hand-writing every HTTP call. They wrap request creation, audit records, evidence reads, and webhook verification while keeping the same public runtime API underneath.
Operator console calls are dashboard APIs, not public agent runtime APIs. They are session-authenticated, role-gated, audited, and intentionally not documented path-by-path on the public site.
Use the dashboard for claiming, viewing, responding to, reassigning, and escalating requests. If you need embedded operator workflows for an enterprise deployment, use a scoped integration path rather than the internal dashboard contract.
Admin, organization-management, Slack, and webhook-secret operations are dashboard APIs. They are for authenticated admins and managers, not for production agents.
The public docs describe the capabilities rather than listing internal paths: manage members and roles, map external approval roles, configure departments and shifts, create API keys, rotate webhook signing material, inspect activity, and connect Slack.
For enterprise management automation, use a scoped admin API engagement with explicit scopes, audit logging, rate limits, and separate credentials from runtime agent keys.
If you want to automate organization administration, do not call dashboard session endpoints from an agent. Use a dedicated management integration with least-privilege scopes such as org read, operator write, routing write, shift write, or webhook-secret rotation.
Keep runtime approval keys and admin automation credentials separate. Runtime keys should create and inspect agent requests; management credentials should be narrow, audited, and issued only to trusted automation.
Contact us for enterprise automation · Authentication and API key handling
Yes for agent runtime calls under /api/centcom/v1. Dashboard, admin, auth, and Slack routes are not part of the public runtime contract.
Most agents create POST /requests for actions that need approval and wait for the signed webhook callback. Use POST /requests/control-map when complex routing needs a preview.
Yes. Operator roles are stored as an array, and external role mappings can point multiple external roles to the same reviewer. Separation-of-duties policies still require distinct people for distinct approvals.
A practical walkthrough of the Contro1 runtime API: which endpoint an agent calls, when to call it, what to send, and how approvals, audit records, traces, and evidence fit together.
Install and use the framework-agnostic Contro1 Python SDK to request human approvals or input, verify signed webhooks, log autonomous actions, and fetch audit evidence.
Install and use @contro1/sdk in Node, TypeScript, Express, Fastify, or Next.js backends to create approval requests, verify webhooks, and write audit records.
Learn how to create, inspect, and cancel Contro1 requests for approvals, clarifications, and escalations.
Use Contro1 audit records to log actions that agents are authorized to run autonomously, and correlation_id to connect requests and logs into one case timeline.
Secure your Contro1 integrations with environment-based API keys, role-aware routing, and clear ownership boundaries.