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.
Managed runtime inclusion
When you have a managed OpenClaw runtime (identified byopenclawInstanceId 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
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
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
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)
Request body
Response
Errors
Delete agent
Response (backend)
Response (web proxy)
The web proxy also acceptsDELETE /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
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 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. 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
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
Query parameters
Response
Get definition
Path parameters
Response
Returns the fullAgentDefinition object:
Errors
Validate definition
Request body
Response
Errors
Clone agent
Response (501 Not Implemented)
501 regardless of the request body. No payment flow is initiated.
Errors
Clone service health
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
502 error with null metric fields instead of fabricated data.
Response (live)
Response (degraded — 502)
When the backend is unavailable, the endpoint returns502 with "status": "degraded" and all metric fields set to null:
docker start.
Backend direct:
POST /api/instance/:userId/start):
Errors
Stop agent
docker stop. The container retains its data and configuration and can be resumed with the start endpoint.
Backend direct:
POST /api/instance/:userId/stop):
Errors
Restart agent
Web proxy (
POST /api/instance/:userId/restart):
Errors
Update agent 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.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
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
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:503 when managed runtime controls are disabled or when the platform cannot resolve the agent’s service configuration:
Get instance details
Response
Get instance stats
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
"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 indetails:
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
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 youropenclawInstanceId 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: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
404, the verification state is persisted locally and the same success response shape is returned.
Errors
Remove verification
404, the endpoint clears the local verification state instead.
Errors
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 by resolving a single email and checking it against the configuredADMIN_EMAILS:
- Session email — if an authenticated session exists, the session email is used.
- Body email fallback — if no session email is available (for example, the session is missing or the session user has no email), the
emailfield in the request body is used instead.
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.
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.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 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.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 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)
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)
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
Get user OpenClaw instance
autoProvision is true or agentType is business. Requires session authentication.
Response
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
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.