Gateway
The v1 gateway routes incoming requests to registered plugins. It supports three payment methods — Stripe (existing), MPP (Machine Payments Protocol) via the Tempo blockchain, and session-based billing for low-latency, off-chain per-call payments.Base URL
Request
Headers
Body
Additional body fields are forwarded to the target plugin.
Plugins
The gateway routes to the following plugins:agent is the default plugin when no plugin ID is specified.Authentication
No plugins currently require authentication. The gateway checks whether a plugin has itsauth flag enabled — since no built-in plugin sets this flag, all requests are processed without requiring a session, MPP credential, or payment session. If a custom plugin is registered with auth: true, the gateway enforces either a valid session (cookie-based via NextAuth), a verified MPP payment credential, or an active payment session. If you pay with MPP or use session-based billing, cookie-based authentication is not required for auth-enabled plugins.
Payment flow
The gateway supports three payment methods per request:- Stripe — Default. Requires an active subscription or credits. See Stripe integration.
- MPP — Crypto-native payments on the Tempo blockchain. See MPP payments.
- Session — Off-chain, per-call billing using a pre-funded payment session. See MPP payments — sessions and the wallet sessions API.
X-Payment-Methodheader (session,mpp, orstripe)- Presence of an
Authorization: Paymentheader (impliesmpp) - Default:
stripe
MPP 402 challenge
When an MPP request has no valid credential, the gateway returns402 Payment Required with pricing information for both payment methods:
WWW-Authenticate header is also set:
Session-based billing
WhenX-Payment-Method is session, the gateway auto-debits the caller’s payment session using an off-chain voucher. This avoids the 402 challenge/response round-trip and settles each call in sub-100ms.
To use session-based billing:
- Open a payment session via
POST /api/wallet/sessions. See wallet sessions. - Include
X-Session-IdandX-Wallet-Addressheaders on every gateway request. - The gateway looks up the session, verifies the balance covers the plugin price, and debits the session automatically.
- The response includes a
Payment-Receiptheader with the voucher reference and anX-Session-Remainingheader with the updated balance.
402 with a descriptive error. See error responses for the full list of session-related error codes.
Response
Success (200)
Payment-Receipt header and the payment.receipt field contains the transaction hash. When paid via a session, the payment.receipt field contains the voucher reference (formatted as session:<sessionId>:<nonce>).
Response headers
Error responses
Gateway chat proxy (WebSocket fallback)
The primary chat endpoint
POST /api/chat now uses the OpenAI-compatible REST API (POST /v1/chat/completions) instead of WebSocket. This WebSocket-based endpoint is retained as a fallback for gateways that do not have chatCompletions enabled. For new integrations, prefer POST /api/chat.openclawUrl values from the database are no longer used for routing.
Requires session authentication.
Request body
Response (200)
Errors
This endpoint opens a WebSocket connection per request and times out after 30 seconds. If the gateway rejects the authentication handshake, a
500 error is returned with details from the gateway. For lower-overhead chat that avoids WebSocket, use POST /api/chat which uses the OpenAI-compatible REST API.Example
Gateway status
Response
Errors
Example
Production gateway service
The production gateway is a standalone service deployed on Railway that exposes an OpenAI-compatible chat completions endpoint. It runs separately from the per-agent containers and uses its own configuration file.Environment variables
OpenClaw configuration env section
The production gateway configuration includes a top-level env section in openclaw.json that passes secrets directly to the OpenClaw runtime. This is separate from container-level environment variables — the env section is read by OpenClaw at startup to authenticate with external services.
Default model configuration
The production gateway uses the following model defaults:
Model aliases are configured for convenience:
Agent defaults
Tool configuration
Session configuration
Cron configuration
Logging configuration
Gateway settings
Health check
The production gateway exposes a/healthz endpoint for Railway health monitoring. Railway is configured to check this path with a 90-second timeout and will restart the service on failure (up to 10 retries).
Per-agent gateway authentication
Each agent container receives a unique gateway auth token at provisioning time. The internal gateway authenticates requests using token-based auth on port18789.
The container entrypoint writes its own minimal configuration to
$HOME/.openclaw/openclaw.json using a slightly different schema (auth.method at the top level instead of gateway.auth.mode). The provisioning config written by the backend uses the gateway.auth.mode path. When the entrypoint runs, it overwrites the provisioning config with its own minimal skeleton. All provisioning paths include a top-level env section containing OPENROUTER_API_KEY so the OpenClaw runtime can authenticate with the LLM provider. To preserve the full provisioning config, pass the gateway token via the OPENCLAW_GATEWAY_TOKEN environment variable so the entrypoint uses the same token.Agent container configuration
When an agent is provisioned, the backend generates an OpenClaw configuration with the following parameters. These values are set automatically and cannot be overridden by the caller.OpenClaw configuration env section
Each agent container’s openclaw.json includes a top-level env section that passes secrets to the OpenClaw runtime. All three provisioning paths (production gateway entrypoint, Railway direct provisioning, and backend container manager) write this section into the configuration file at launch.
The
env section in openclaw.json is distinct from the container-level environment variables listed below. Container environment variables are set on the container process by the orchestrator (Railway or Docker). The env section is read by the OpenClaw runtime from its configuration file and used internally for service authentication. Both mechanisms deliver the same OPENROUTER_API_KEY value, but the config-file path ensures OpenClaw can access the key even when the runtime does not inherit the container’s full environment.Container environment variables
The following environment variables are set on every agent container at launch. Variables are grouped by source — some are set by the container image entrypoint (local Docker path) and others are injected by the provisioning service (Railway path). When both paths set the same variable, the provisioning service value takes precedence.Gateway settings
Tool settings
Session settings
Agent defaults
Health monitoring
The gateway monitors channel health for each agent container. When a channel becomes unresponsive, the gateway can automatically restart it.CORS
The gateway supports CORS preflight viaOPTIONS /api/v1/gateway. Allowed methods are GET, POST, and OPTIONS. The Content-Type, Authorization, X-Plugin-Id, and Payment headers are permitted in the CORS configuration.