Agents API
Create, manage, and interact with agents.All agent endpoints that require authentication are scoped to the authenticated user’s data through row-level security. You can only access agents that belong to your account.
List agents
401 error.
Response (backend)
The backend returns a flat array of agent objects:Response (web proxy)
The web proxy wraps the response in an object:The backend and web proxy return different response shapes. The backend returns a flat array with
created, subdomain, and url fields. The web proxy wraps the data in an agents key and includes name, model, websocketUrl, createdAt, and updatedAt fields.Create agent
Request body
Response (201 Created)
Errors
For provisioning an agent with messaging channel tokens and a live Railway service deployment, use
POST /api/agents/provision or POST /api/provision instead.Get agent
Response (backend)
The backend returns the agent object directly without a wrapper:Response (web proxy)
The web proxy wraps the agent in an object:The backend returns the agent object directly. The web proxy wraps it in an
agent key and adds a top-level status field set to "ok".Errors
Rename agent
Request body
Response
Errors
Update agent
Request body
Response
Errors
To update agent configuration through the web proxy with session authentication, use
PUT /api/agents/:id/config instead.Delete agent
Response
Errors
The backend uses best-effort cleanup (service destruction and metadata removal). If the agent does not exist, the operation succeeds silently and returns
deleted: true.Provision agent
The agent is created immediately with a
provisioning status and transitions to running once the backend deployment endpoint confirms the deployment. If deployment fails, the status changes to error.The provisioning endpoint calls
POST /api/deployments on the backend to deploy the agent as a Railway service. The request includes a 15-second timeout. When the model is set to claude-opus-4-6, the AI provider is automatically set to anthropic; otherwise it falls back to the provider specified in the agent configuration (default: openrouter). The plan sent to the backend defaults to label when no tier is specified.Request body
The web proxy enforces agent limits based on the subscription tier (
starter: 1, pro: 3, enterprise: 100). The backend provisioning route (POST /api/provision) enforces its own limits (solo: 1, collective: 3, label: 10, network: unlimited). These provisioning limits determine how many agents you can create. The plan middleware enforces separate per-request limits for AI model access and skill usage. The limit cannot be overridden in the request body.The backend also accepts legacy plan aliases for resource allocation:
underground (2 GB / 1 CPU), starter (2 GB / 1 CPU), pro (4 GB / 2 CPU), scale (8 GB / 4 CPU), enterprise (16 GB / 4 CPU), and white_glove (32 GB / 8 CPU). These are accepted in addition to the standard plan names (solo, collective, label, network) when determining container resource limits.Admin bypass
Admin users (configured viaADMIN_EMAILS) are exempt from the following restrictions:
- Subscription requirement — admins can provision agents without an active subscription (the
402error is not returned). - Agent limit — admins receive an elevated agent slot limit instead of the plan-based cap.
ADMIN_EMAILS. This endpoint does not accept an email field in the request body — only the authenticated session email is used for the admin check. The POST /api/provision endpoint uses the same session-only admin check (see admin check).
The backend also supports a
TESTER_EMAILS environment variable. When backend payment enforcement is re-enabled, emails listed in TESTER_EMAILS will bypass the Stripe subscription check, similar to admin emails. This feature is currently inactive because backend payment enforcement is disabled (see the 402 error note below).Response (201 Created)
Errors
Clone agent
Response (501 Not Implemented)
501 regardless of the request body. No payment flow is initiated.
Errors
Clone service health
Preflight checks (deprecated)
Query parameters
Response
This endpoint no longer returns a response. The previous response includedchecks, pipeline, and nextAction fields.
List provisioned agents
Response
Errors
Get agent configuration
Response
Errors
Update agent configuration
Response
Errors
Get agent logs
Query parameters
Response
Errors
Stream agent logs
The live log streaming endpoints (
/api/logs/:agentId/stream, /api/logs/:agentId/history, POST /api/logs/:agentId/stop, and GET /api/logs/active) are planned for a future release. See the live log tail page for the intended specification.Get agent messages
Query parameters
Response
Errors
Get agent stats
Response (live)
Response (mock fallback)
When the backend is unavailable, mock data is returned with"status": "mock":
Agent lifecycle
Lifecycle operations are available at two endpoint patterns depending on which service you call:- Web proxy:
/api/instance/:userId/{action}— requires session authentication and proxies to the backend. - Backend direct:
/api/agents/:id/{action}— requires API key authentication.
The backend agents route uses local Docker commands (
docker start, docker stop, docker restart) for lifecycle operations, not the Railway API. The Railway API is used by the provisioning route (POST /api/provision) for creating new agent services. When Docker is unavailable on the backend host, lifecycle operations return 500 with an error message. You can check availability using the backend health endpoint — when the docker field is unavailable, lifecycle operations will fail.Start agent
Stop agent
Restart agent
Update agent image
Request body
Response
When the new service fails to start, the endpoint reverts to
previousImage. The caller still receives a 500 error, but the agent is restored to its prior working state. The pre-update backup remains available at backupPath for manual recovery if needed.Errors
Repair agent
Reset agent memory
Lifecycle error responses
Backend lifecycle endpoints return the following shape on failure:Get instance details
Response
Get instance stats
- Backend API — queries the backend service for full resource metrics (CPU, memory, plan, version).
- Agent health probe — when the backend is unavailable (for example, returns
503when suspended), the endpoint probes the agent’s own/healthzand/readyzendpoints directly on Railway. This returns health status instead of full resource metrics.
Response (backend available)
When the backend API responds successfully, the full resource metrics are returned:Response (backend unavailable, agent healthy)
When the backend is down but the agent’s Railway service is reachable, the endpoint probes the agent’s/healthz endpoint. If /healthz reports the agent is live, the endpoint also probes /readyz to determine readiness.
When the backend is unavailable, CPU and memory metrics cannot be retrieved because the agent’s
/healthz and /readyz endpoints do not report resource usage. The cpu and memory fields return "—" to indicate that the agent is running but detailed metrics are unavailable.Response (both unreachable)
When both the backend and the agent’s Railway service are unreachable:Errors
Get agent gateway token
OPENCLAW_GATEWAY_TOKEN environment variable is not set) use 24 bytes (48 hex characters).
Errors
Agent verification
Agents can be verified using multiple verification types:eas (Ethereum Attestation Service), coinbase, ens, or webauthn.
Get verification status
The backend GET endpoint uses
/api/agents/:id/verification while POST and DELETE use /api/agents/:id/verify. The web API proxies all three methods through /api/agents/:id/verify.Verify agent
Request body
Requires
Content-Type: application/json header.The web API always sets
verified: true on success and computes the verifierAddress and metadata fields internally based on the verification type. When calling the backend directly, you can pass verified, verifierAddress, and metadata explicitly.Response
Errors
Remove verification
Provision with channel tokens
autoProvision is true or agentType is business, channel tokens are not required and the agent is provisioned as an OpenClaw-only deployment. Otherwise, at least one channel token (Telegram, WhatsApp, or Discord) is required.
Admin check
Admin status is determined using the session email only. Theemail field in the request body is not used for admin resolution.
- Session email — the email from the authenticated session is checked against the configured
ADMIN_EMAILS.
401 error.
The body
email field is no longer used as a fallback for admin detection. Only the session email is checked. This is a change from previous behavior where the body email was checked when no session email was available.Provisioning strategy
The endpoint provisions agents using a two-path strategy, tried in order:- Backend service — the request is forwarded to the backend Express service (
BACKEND_API_URL). If a fallback URL is configured (BACKEND_API_FALLBACK_URL), it is tried next if the primary fails. Non-JSON responses (such as HTML error pages from a proxy or load balancer) are detected and treated as failures, avoiding the previous “Unexpected token” parsing errors. - Railway direct provisioning — when all backend URLs fail or are not configured, the endpoint falls back to provisioning the agent container directly via the Railway GraphQL API. This path requires
RAILWAY_API_KEY,RAILWAY_PROJECT_ID, andRAILWAY_ENVIRONMENT_IDto be set. The Railway path creates a new Railway service, injects environment variables (includingOPENCLAW_GATEWAY_PORT=18789), sets a start command via theServiceInstanceUpdatemutation that configures the gateway (local mode, disabled device auth, enabled chat completions endpoint), generates a public domain via theserviceDomainCreatemutation withtargetPort: 18789so that Railway’s HTTP proxy routes traffic directly to the gateway port, and then triggers a deployment. The domain is generated before the deploy so that the service has a routable public URL immediately. The returned URL is the direct Railway domain for the service. ThecontrolUiUrlis constructed withgatewayUrlandtokenquery parameters so the Control UI auto-connects without requiring manual configuration.
502 error.
When the backend path succeeds and MUX_TOKEN_ID and MUX_TOKEN_SECRET are configured, the backend creates a real Mux live stream via the Mux API with public playback policy. When Mux credentials are not configured, placeholder streaming credentials are returned instead. The Railway direct path does not create Mux streams.
Request body
The server resolves the user email exclusively from the authenticated session. The session email is sent to the backend provisioning service in the
X-User-Email header and the session user ID is sent in the X-User-Id header. The email field in the request body is not used for authentication or admin detection.Response
The response shape depends on which provisioning path succeeds.Backend path response
When the backend Express service handles the request, the proxy returns a filtered subset:The backend path returns
success, userId, subdomain, url, streamKey, and liveStreamId. The full response shape from the backend provisioning service is shown below.Railway direct path response
When the Railway fallback handles the request, the response has a different shape:The Railway path does not return
subdomain, streamKey, or liveStreamId. These fields are only available when the backend Express service handles the request. The status field is deploying (not active) because the Railway service is created asynchronously. The Railway path creates a service domain with targetPort: 18789 so that Railway’s HTTP proxy routes incoming requests directly to the OpenClaw gateway port. The start command configures the gateway in local mode with device auth disabled and chat completions enabled before launching on port 18789.On a successful provision through either path, the proxy persists the
openclawUrl and openclawInstanceId to the user record in the database. You can retrieve these values later using GET /api/user/openclaw.Full backend response
When calling the backend provisioning service directly, the response includes additional fields. The backend returns200 OK on success (not 201 Created).
The
container object is included when the backend successfully creates a container for the agent. If container creation fails, provisioning still succeeds and the container field is omitted. The agent can operate using API-side processing until the container becomes available. You can check backend availability using the backend health endpoint.The
container.status is deploying because the Railway service is created asynchronously. The service transitions to running once the deployment completes. Device pairing (dangerouslyDisableDeviceAuth) is automatically disabled for user containers at provisioning time — each user has an isolated container, so device auth is unnecessary. The gateway is still protected by token authentication (OPENCLAW_GATEWAY_TOKEN). The service domain is created with targetPort: 18789 so that Railway’s HTTP proxy routes traffic directly to the gateway port.Errors
AI provider defaults
EachaiProvider value maps to a default model and base URL. There are two model configurations: the container config (used by the agent’s internal gateway) and the provision response metadata (aiProviderConfig field). These may differ.
Container config models
These models are configured inside the agent service at provisioning time and are used by the gateway’s model fallback chain:Provision response metadata models
TheaiProviderConfig object returned in the provision response uses different default models:
Each provider includes a fallback model in the service config that is used automatically when the primary model is unavailable or returns an error.
minimax is available as a fallback in the provider configuration map but is not currently accepted as a value for the aiProvider request parameter. Passing minimax as aiProvider returns a 400 validation error. This provider may be enabled in a future release.Channel configuration
When an agent is provisioned, its channel configuration is generated based on the tokens provided. All channels share a set of defaults and each channel type has specific settings.Channel defaults
Telegram channel settings
Discord channel settings
WhatsApp channel settings
Group chat mention patterns
All channels that support group chat use the following default mention patterns:@agent and agent. The agent only responds in group conversations when one of these patterns is detected in the message.
Tool profiles
Each agent is assigned a tool profile at provisioning time based on its plan tier. The tool profile determines which built-in tools the agent can use.The tool profile is set once at service creation and persists for the lifetime of the agent. Upgrading your plan does not automatically change the tool profile of existing agents — you need to reprovision the agent or use the repair endpoint to apply the new profile.
browser and canvas tools inside agent services. The coding profile includes shell commands (ls, cat, grep, curl, git, node, python3, and others) while the messaging profile restricts the agent to chat-oriented capabilities.
Deploy agent (backend)
This is a backend-only endpoint. It deploys an agent as a Railway service and requires a
Content-Type: application/json header. Requires bearer token authentication. Rate limited to 5 requests per minute per IP.Request body
Response (201 Created)
Response (200 Already Active)
If the agent service is already running, returns the existing deployment details with the same shape as the 201 response.Errors
OpenClaw version (backend)
Response
deployedAt returns the current server time when the request is made, not the actual deployment time of the OpenClaw runtime.List instances (backend)
Response
The
metadata object contains the full agent metadata from the on-disk JSON file and may include additional fields beyond those shown (for example, aiProvider, port, subdomain, url, status, and config).Errors
Get instance service stats (backend)
Path parameters
Response
Proxy to agent instance (backend)
/api/openclaw/proxy/:agentId prefix from the request path before forwarding. WebSocket upgrades are also supported and handled at the server level.
No additional authentication is required on the proxy itself — the agent’s own token authentication handles access control.
Path parameters
Errors
The proxy rewrites the request path so that
/api/openclaw/proxy/agent_123/some/path forwards to /some/path on the agent’s internal address. If no path follows the agent ID, the request is forwarded to /.Get user OpenClaw instance
autoProvision is true or agentType is business. The gateway token is a platform-level credential used to authenticate with the OpenClaw Control dashboard. Requires session authentication.
Response
Fix OpenClaw start command (admin)
gateway.trustedProxies and gateway.controlUi.allowedOrigins before launching the OpenClaw process.
Query parameters
Response
This endpoint no longer returns a response. Any request will result in a404.
Agent interaction
userId is always bound to the authenticated session and cannot be overridden by the client.
GET actions
Pass theaction query parameter to select the operation.
List endpoints
Health
List sessions
Get session
Memory
Skills
Credentials
POST actions
Pass theaction field in the request body.
Chat
Create session
Update skill
Set credential
Errors
Send message
POST /v1/chat/completions with a bearer token. The gateway must have chatCompletions enabled in its configuration.
Requires session authentication.
Request body
Response (200)
Errors
The server sends an HTTP POST request to the agent’s gateway for each call. Requests time out after 30 seconds. If the gateway is unreachable or the agent does not respond within this window, a
502 or 500 error is returned.