Skip to main content

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

Returns all agents owned by the authenticated user. When no session is present, returns an empty list instead of a 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

Creates a new agent with an auto-generated ID and stores its metadata on disk. Requires bearer token authentication (backend).

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

Requires authentication and ownership of the 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

Renames an agent. Requires session authentication and ownership of the agent. The name is updated in the database immediately. The endpoint also makes a best-effort attempt to sync the new name to the backend — if the backend is unreachable, the rename still succeeds (the database is the source of truth for agent names).

Request body

Response

Errors

Update agent

Updates an agent’s metadata including plan, AI provider, and configuration. Requires bearer token authentication (backend).

Request body

Response

Errors

To update agent configuration through the web proxy with session authentication, use PUT /api/agents/:id/config instead.

Delete agent

Stops and removes the agent’s local Docker container, deallocates its port, and removes its metadata file. Requires bearer token authentication (backend).

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

Provisions a new agent. Requires an active subscription unless the caller is an admin.
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 via ADMIN_EMAILS) are exempt from the following restrictions:
  • Subscription requirement — admins can provision agents without an active subscription (the 402 error is not returned).
  • Agent limit — admins receive an elevated agent slot limit instead of the plan-based cap.
Admin status is determined by checking the session email against 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

Not yet available. Agent cloning is under development and this endpoint currently returns 501 Not Implemented. No payment is processed. The request body is ignored.

Response (501 Not Implemented)

All POST requests to this endpoint return 501 regardless of the request body. No payment flow is initiated.

Errors

Clone service health

Returns the clone service status and protocol configuration. No authentication required.

Preflight checks (deprecated)

This endpoint has been deprecated and is no longer available. Requests to this endpoint will return a 404 error.
Validates all requirements before performing an operation on an agent. Returns a step-by-step checklist with the status of each prerequisite and the next recommended action.

Query parameters

Response

This endpoint no longer returns a response. The previous response included checks, pipeline, and nextAction fields.

List provisioned agents

Requires session authentication.

Response

Errors

Get agent configuration

Returns the current configuration for an agent. Requires authentication and ownership.

Response

Errors

Update agent configuration

Updates the configuration for an agent. Requires authentication and ownership. The request body is forwarded to the backend.

Response

Errors

Get agent logs

Returns logs for an agent. Requires authentication and ownership.
This endpoint currently returns mock data. Log entries are generated placeholders, not real agent logs. For real-time logs, use the live log stream endpoint instead.

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

Returns paginated messages for an agent. Requires authentication and ownership.

Query parameters

Response

This endpoint currently returns mock data. Message entries are generated placeholders. A future release will connect this endpoint to the backend message store.

Errors

Get agent stats

Returns live service metrics when available, with a mock fallback.

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.
Both patterns support the same actions. The examples below use the backend pattern.
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

Restarts (redeploys) a stopped agent service.

Stop agent

Stops the agent service. The service retains its data and configuration and can be resumed with the start endpoint.

Restart agent

Update agent image

Triggers an image update on the backend. Before replacing the service, the endpoint creates a backup of the agent’s data. If the new image fails to start, the endpoint automatically rolls back to the previous 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

Returns the backend response directly.

Reset agent memory

Returns the backend response directly.

Lifecycle error responses

Backend lifecycle endpoints return the following shape on failure:
Web proxy lifecycle endpoints return a different error shape:

Get instance details

Returns the current status and metadata for an agent instance.

Response

Get instance stats

Returns resource usage statistics for an agent instance. Requires session authentication and ownership of the instance. The endpoint uses a two-tier fallback strategy:
  1. Backend API — queries the backend service for full resource metrics (CPU, memory, plan, version).
  2. Agent health probe — when the backend is unavailable (for example, returns 503 when suspended), the endpoint probes the agent’s own /healthz and /readyz endpoints directly on Railway. This returns health status instead of full resource metrics.
If both the backend and the agent are unreachable, the endpoint returns a minimal response indicating the stats service is unavailable.

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

Returns the gateway token for the agent. If no token exists, a new cryptographically random token is generated using 32 bytes of entropy (returned as a 64-character hex string). Tokens generated by the service entrypoint (when the 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.
Each verification type requires a different combination of fields:

Response

Errors

Remove verification

Provision with channel tokens

Provisions a new agent with messaging channel tokens. Requires session authentication. When a session is active, the user’s email is automatically resolved from it. When 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. The email field in the request body is not used for admin resolution.
  1. Session email — the email from the authenticated session is checked against the configured ADMIN_EMAILS.
If the session email matches an admin email, the caller is treated as an admin. When the session is missing but the session email resolves to an admin, a synthetic session is created and the request proceeds. Non-admin users without a valid session receive a 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.
This endpoint is subject to the general rate limit of 120 requests per minute per IP.

Provisioning strategy

The endpoint provisions agents using a two-path strategy, tried in order:
  1. 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.
  2. 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, and RAILWAY_ENVIRONMENT_ID to be set. The Railway path creates a new Railway service, injects environment variables (including OPENCLAW_GATEWAY_PORT=18789), sets a start command via the ServiceInstanceUpdate mutation that configures the gateway (local mode, disabled device auth, enabled chat completions endpoint), generates a public domain via the serviceDomainCreate mutation with targetPort: 18789 so 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. The controlUiUrl is constructed with gatewayUrl and token query parameters so the Control UI auto-connects without requiring manual configuration.
If both paths fail, the endpoint returns a 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.
The following request fields are deprecated and no longer accepted: whatsappPhoneNumberId, whatsappBusinessAccountId, discordGuildId, discordChannelId.

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 returns 200 OK on success (not 201 Created).
Channel tokens (telegramToken, discordBotToken, whatsappToken) are no longer included in the provision response. Tokens are write-only secrets — they are stored server-side but never returned to the caller.
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

Each aiProvider 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

The aiProviderConfig 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.
All tool profiles deny 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)

Returns the current OpenClaw runtime version. Requires bearer token authentication.

Response

deployedAt returns the current server time when the request is made, not the actual deployment time of the OpenClaw runtime.

List instances (backend)

Returns all running agent services. Requires bearer token authentication.

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)

Returns resource usage for a specific agent service. Requires bearer token authentication.

Path parameters

Response

Proxy to agent instance (backend)

Transparently forwards HTTP requests to the agent’s internal service address. The proxy strips the /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

Returns the authenticated user’s OpenClaw URL, instance ID, and gateway token. These values are set during provisioning when 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)

Deprecated. This endpoint has been removed and is no longer available. It was a one-time administrative utility.
Previously updated the OpenClaw service start command on Railway and triggered a redeploy. The updated start command wrote a gateway configuration file with 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 a 404.

Agent interaction

Unified endpoint for interacting with agents. All requests require session authentication. The userId is always bound to the authenticated session and cannot be overridden by the client.

GET actions

Pass the action query parameter to select the operation.

List endpoints

Returns available endpoints and version information when no action is specified.

Health

List sessions

Get session

Returns the full session including messages.

Memory

Returns the last 10 messages from the active session (truncated to 100 characters each).

Skills

Returns skills available on the agent instance.

Credentials

Returns which credentials are configured for the agent.

POST actions

Pass the action field in the request body.

Chat

Create session

Update skill

Set credential

Errors

Send message

Sends a message to the caller’s deployed agent via the OpenAI-compatible REST API. The server forwards the message to the agent’s gateway using POST /v1/chat/completions with a bearer token. The gateway must have chatCompletions enabled in its configuration. Requires session authentication.

Request body

The topic parameter was removed. Conversation context is no longer passed through this endpoint. If you need to route messages to a specific conversation, use the gateway chat proxy which supports a sessionKey parameter.

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.

List messages

Returns the message history. Requires session authentication.

Response

Errors