Skip to main content

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 its auth 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:
  1. Stripe — Default. Requires an active subscription or credits. See Stripe integration.
  2. MPP — Crypto-native payments on the Tempo blockchain. See MPP payments.
  3. Session — Off-chain, per-call billing using a pre-funded payment session. See MPP payments — sessions and the wallet sessions API.
The server selects the payment method using the following priority:
  1. X-Payment-Method header (session, mpp, or stripe)
  2. Presence of an Authorization: Payment header (implies mpp)
  3. Default: stripe

MPP 402 challenge

When an MPP request has no valid credential, the gateway returns 402 Payment Required with pricing information for both payment methods:
The WWW-Authenticate header is also set:

Session-based billing

When X-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:
  1. Open a payment session via POST /api/wallet/sessions. See wallet sessions.
  2. Include X-Session-Id and X-Wallet-Address headers on every gateway request.
  3. The gateway looks up the session, verifies the balance covers the plugin price, and debits the session automatically.
  4. The response includes a Payment-Receipt header with the voucher reference and an X-Session-Remaining header with the updated balance.
If the session is missing, expired, or has insufficient balance, the gateway returns 402 with a descriptive error. See error responses for the full list of session-related error codes.

Response

Success (200)

When paid via MPP, the response includes a 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)

Sends a chat message to the caller’s deployed agent through the OpenClaw Gateway using WebSocket. The server connects to the agent’s gateway via WebSocket, authenticates using the challenge-response handshake, delivers the message, and returns the agent’s reply.
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.
This endpoint retrieves the gateway token dynamically from the backend API rather than relying on a single environment variable. 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

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 port 18789.
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. 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.

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 via OPTIONS /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.
The X-Payment-Method, X-Session-Id, and X-Wallet-Address headers are read server-side but are not included in the CORS Access-Control-Allow-Headers response. Cross-origin requests that include these headers may be rejected by the browser preflight check. Same-origin requests are unaffected. If you need to send these headers from a different origin, configure the GATEWAY_CORS_ORIGIN environment variable or proxy the request through a same-origin endpoint.

OpenAI-compatible endpoints

The gateway exposes a set of endpoints that follow the OpenAI API format. These allow you to use Agentbot as a drop-in replacement for the OpenAI SDK or any tool that supports the OpenAI API shape.

List models

Returns all available models in OpenAI-compatible format. This endpoint is public and does not require authentication.

Response (200)

Model object

Errors

Retrieve a model

Returns details for a single model by its ID. This endpoint is public and does not require authentication.

Path parameters

Response (200)

Errors

Create embeddings

Generates embeddings for the given input. Proxies the request to OpenRouter. Requires authentication.

Headers

Request body

Response (200)

The response follows the OpenAI embeddings format. The exact shape depends on the upstream provider.

Errors

Rate limits

Examples

Route a request to the agent plugin (Stripe)

Route a request with MPP payment

Route a request with session-based billing

The response includes the remaining session balance:

List available models (OpenAI-compatible)

Retrieve a specific model

Generate embeddings