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.

Managed runtime inclusion

When you have a managed OpenClaw runtime (identified by openclawInstanceId on your user record) but no corresponding agent row exists in the database, the endpoint automatically includes a synthetic agent entry in the response. This ensures that managed runtimes are always visible in the agents list, even before a skill installation or other action has materialized the database row. The synthetic entry uses the following defaults:
The synthetic agent is generated in-memory and is not persisted to the database. It appears only in the listing response. When a database row is later created for the same openclawInstanceId (for example, during skill installation), the synthetic entry is no longer needed and the persisted row is returned instead.

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 Render 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. Sensitive fields (config.authToken and top-level authToken) are stripped from the response before it is returned to the client.

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.

Rename agent (web proxy)

Renames an agent. Requires session authentication and ownership. The name change is persisted locally and forwarded to the backend on a best-effort basis (backend failures are non-fatal).

Request body

Response

Errors

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 (backend)

Response (web proxy)

The web proxy also accepts DELETE /api/agents/:id with session authentication. It performs best-effort cleanup of the associated managed runtime service, deletes the agent record from the database (cascading to memories, files, and related data), and clears the user’s openclawInstanceId and openclawUrl fields. The agent is resolved by ownership check or by matching the user’s openclawInstanceId.

Errors

The backend uses best-effort cleanup (service destruction and metadata removal). If the agent metadata does not exist, the endpoint returns 404 before attempting cleanup. Container stop and removal failures are silently ignored.

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. After a successful deployment, the provisioning endpoint also syncs the agent’s skills, memories, and files to the OpenClaw gateway. If the gateway is unreachable, the agent is set to pending_gateway_sync instead of failing outright — the sync can be retried later.
The provisioning endpoint calls POST /api/deployments on the backend to deploy the agent as a Render 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.
The provisioning endpoint connects to the OpenClaw gateway using the OPENCLAW_GATEWAY_URL environment variable. When this variable is not set, the endpoint falls back to the default internal gateway address. You can configure this variable in your environment to point to a custom gateway deployment. See environment variables for details.

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: 999999). The plan middleware enforces a separate set of agent limits for AI model access (solo: 1, collective: 3, label: 10, network: 100). The provisioning limits and middleware limits apply independently. 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. See admin check in the POST /api/provision section for the legacy endpoint’s resolution order, which also supports a body email fallback when no session is present.
Backend payment enforcement is active. All paid plans require a valid Stripe subscription ID unless the caller is an admin (configured via ADMIN_EMAILS).

Response (201 Created)

Errors

Token sponsorship simulator

Calculates token economics for agent sponsorship. Supports two modes: forward (set liquidity tokens to calculate market cap) and reverse (set desired market cap to calculate required liquidity tokens). No authentication required.

Query parameters

Forward mode example

Reverse mode example

Response

Errors

Agent definitions

Manage agent definitions stored as markdown files with YAML frontmatter. These endpoints are backend-only and require bearer token authentication.

List definitions

Returns all available agent definitions loaded from system, user, and project directories.

Query parameters

Response

Get definition

Returns a single agent definition by name, including the full instruction body.

Path parameters

Response

Returns the full AgentDefinition object:

Errors

Validate definition

Validates and previews an agent definition without saving it. Accepts raw markdown with YAML frontmatter.

Request body

Response

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.

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. When the backend is unavailable, the endpoint returns a 502 error with null metric fields instead of fabricated data.

Response (live)

Response (degraded — 502)

When the backend is unavailable, the endpoint returns 502 with "status": "degraded" and all metric fields set to null:
This endpoint no longer returns mock data when the backend is unavailable. Previous versions returned fabricated metrics with "status": "mock". The endpoint now returns 502 with null fields so callers can distinguish between real metrics and a backend outage.
Starts a stopped agent container using docker start. Backend direct:
Web proxy (POST /api/instance/:userId/start):

Errors

Stop agent

Stops the agent container using docker stop. The container retains its data and configuration and can be resumed with the start endpoint. Backend direct:
Web proxy (POST /api/instance/:userId/stop):

Errors

Restart agent

Backend direct:
Web proxy (POST /api/instance/:userId/restart):

Errors

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

Backend direct:
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.
Web proxy (POST /api/instance/:userId/update):
The web proxy update response does not include previousImage or backupPath. On failure, the web proxy returns { "success": false, "status": "error" } — this differs from other web proxy lifecycle endpoints which use { "success": false, "error": "..." }.

Errors

Repair agent

Repairs an agent by reconfiguring its environment and restarting the service. Backend direct — stops the container, heals legacy model configuration, removes the container, and recreates it with the same image.
Web proxy (POST /api/instance/:userId/repair) — reconfigures the agent’s environment variables on the managed runtime and restarts the service. The endpoint injects the user’s unique gateway token retrieved from the agent_registrations table rather than a shared platform token. If no per-user token exists in the database, a new UUID is generated and used instead.
The web proxy repair endpoint always uses the authenticated user’s own gateway token from the database. This ensures each agent authenticates with a token unique to its owner.

Errors

Reset agent memory

Backend direct:
Web proxy (POST /api/instance/:userId/reset-memory) — deletes all stored agent memory rows and restarts the container:

Errors

Lifecycle error responses

Backend lifecycle endpoints return the following shape on failure:
Web proxy lifecycle endpoints return a different error shape. Most endpoints use:
The update endpoint is the exception and returns:
All web proxy lifecycle endpoints return 503 when managed runtime controls are disabled or when the platform cannot resolve the agent’s service configuration:
When service or configuration resolution fails, the error message describes the specific issue:

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.

Response

When the instance is unreachable, the response uses placeholder values:
The openclawVersion field is omitted when the instance is unreachable. The cpu and memory fields currently return placeholder values and will report actual resource metrics in a future release.

Sync agent to gateway

Syncs agent skills, memories, and files to the OpenClaw gateway. Requires session authentication and ownership of the agent. The endpoint verifies that the authenticated user owns the agent by checking the database before proceeding with the sync. Use this endpoint to retry a failed deployment, or to bring the live OpenClaw runtime back in line with the saved install records when an earlier skill install or uninstall returned "deployed": false. A skill is only treated as active in the runtime once a sync succeeds — saved install records alone do not imply the runtime accepted the skill.

Response

When the gateway accepts the sync:
The gateway client validates the sync response body. A 2xx status with "success": false (or a body the client otherwise rejects) is treated as a failed sync and surfaces as a 500 from this endpoint, rather than being reported as a successful deploy.

Errors

When the sync fails, the response includes the underlying gateway error in details:
This endpoint enforces strict ownership. The agent must belong to the authenticated user’s account. Requests for agents owned by other users return 404 to prevent information leakage about agent IDs.

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) also use 32 bytes (64 hex characters).

Errors

Agent verification

Agents can be verified using multiple verification types: eas (Ethereum Attestation Service), coinbase, ens, or webauthn.

Managed runtime fallback

All verification endpoints support a managed runtime fallback. When you have a managed OpenClaw runtime but no corresponding agent row exists in the database, the endpoint automatically resolves the agent by matching your openclawInstanceId and upserts a synthetic agent record. This ensures verification works for managed runtimes even before a full agent record has been provisioned. When the backend verification service returns 404 (for example, because the backend does not yet have metadata for the agent), the web proxy falls back to reading and writing verification state in the agent’s local config.verification field in the database. This means verification state is persisted and readable locally for managed runtimes, even when the backend has no record of the agent.

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.

Response

When the backend is available, the response is proxied as-is:
When the backend returns 404, the endpoint falls back to the locally persisted verification state:
The fallback response does not include the metadata field. All fields default to null (or false for verified) when no local verification state has been written.

Errors

Verify agent

Request body

Requires Content-Type: application/json header.
Each verification type has specific field requirements:
The web API always sets verified: true on success. When calling the backend directly, you can pass verified, verifierAddress, and metadata explicitly.

Response

When the backend returns 404, the verification state is persisted locally and the same success response shape is returned.

Errors

Remove verification

When the backend returns 404, the endpoint clears the local verification state instead.

Errors

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 by resolving a single email and checking it against the configured ADMIN_EMAILS:
  1. Session email — if an authenticated session exists, the session email is used.
  2. Body email fallback — if no session email is available (for example, the session is missing or the session user has no email), the email field in the request body is used instead.
The first available email is checked against ADMIN_EMAILS. If it matches, the caller is treated as an admin. When the session is missing entirely (for example, after a Stripe checkout redirect loses the session cookie) and the body email matches an admin, a synthetic session is created and the request proceeds without requiring a real session. Non-admin users without a valid session receive a 401 error.
Only one email is checked — the session email takes priority. If the session email exists but is not an admin, the body email is not checked as a secondary fallback. This differs from previous behavior where both emails were checked independently.
This endpoint is subject to the general rate limit of 120 requests per minute per IP.
The request is proxied to the backend provisioning service. When 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.

Request body

When a session is active, the server resolves the user email from the session via getServerSession. The session email is used for the admin check. When no session email is available, the email field from the request body is checked against ADMIN_EMAILS — if it matches, a synthetic session is created and the request proceeds. The resolved email is sent to the backend provisioning service in the X-User-Email header.
The following request fields are deprecated and no longer accepted: whatsappPhoneNumberId, whatsappBusinessAccountId, discordGuildId, discordChannelId.

Response

The proxy returns a filtered subset of the backend response:
The /api/provision proxy returns only success, userId, subdomain, url, streamKey, and liveStreamId. The full response shape from the backend provisioning service is shown below.
When provisioning with autoProvision: true or agentType: "business" (OpenClaw-only deployment), the proxy also persists the openclawUrl and openclawInstanceId to the user record. 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.

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 Render web 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

Provision on Railway (backend)

Provisions a new agent service on Railway via the Railway GraphQL API. This endpoint creates a Railway service, configures environment variables, mounts a persistent volume, generates a public domain, and triggers a deployment. Requires bearer token authentication.
This endpoint exists because direct calls from Vercel serverless functions to the Railway GraphQL API return 403. The backend runs on Railway, so its outbound requests to the Railway API succeed. The endpoint requires RAILWAY_API_KEY, RAILWAY_PROJECT_ID, and RAILWAY_ENVIRONMENT_ID environment variables to be configured. Set RAILWAY_TOKEN_TYPE to control how the platform authenticates with the Railway API — project sends the key via the Project-Access-Token header, while account (default), workspace, and oauth send it as a Bearer token in the Authorization header.

Request body

Plan resource limits

Each plan tier maps to specific Railway service resource limits:

Response

The provisioned service is configured with a persistent volume mounted at /data, a health check on /health with a 60-second timeout, and an ON_FAILURE restart policy with up to 10 retries. Environment variable injection retries once on failure with a 2-second delay.

Errors

Idempotency

If a Railway service with the same name already exists (for example, after a partial failure), the endpoint looks up the existing service ID and continues with environment variable injection and deployment. This makes the endpoint safe to retry.

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

Get user OpenClaw instance

Returns the authenticated user’s OpenClaw URL and instance ID. These values are set during provisioning when autoProvision is true or agentType is business. Requires session authentication.

Response

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 your deployed agent. The message is queued for processing via the platform job system and the response is returned asynchronously. Requires session authentication.

Request body

Response (202 Accepted)

The endpoint enqueues the message as a background job and returns immediately with a job reference. Poll the job status using the returned jobId.

Errors

List messages

Returns the message history. Requires session authentication.

Response

Errors