OpenAI-Compatible API

Connect an existing compatible client to the managed Panel gateway. The Panel has a separate engine lifecycle: an API route being registered does not prove a model is running.

1. Open API workbench (/rust/api), then Base URLs. Read the base_url from GET /api/gateway/connect, which reports blocked single-user mode and any published model IDs.
2. In Access and API keys, enable multi-user mode and create an API key. For gateway requests the key belongs in the bearer Authorization header. Store it in a local secret store, never in a URL.
3. Set the existing client's base URL to the gateway's base_url (the Panel origin plus /v1) and its secret to the created key. For command-line samples set PANEL_URL to the origin without /v1.
4. Use GET /v1/models to choose a reported model ID. Submit POST /v1/chat/completions only after a model is available. The endpoint handles chat messages; passing stream:false requests a non-streaming response.
5. In Endpoint catalog, expand Browse every endpoint (generated from route registration) and open POST /v1/chat/completions; administrators may instead select it and press Generate examples. The samples contain MODEL_ID; replace it with the model ID from the inventory.

Example JSON for POST /v1/chat/completions:

{"model":"MODEL_ID","messages":[{"role":"user","content":"Hello"}],"stream":false}

GET /api/openapi.json describes the native Panel route set and authorization metadata. Some HTTP-dispatch gateway routes are separate from that native list; their examples are labeled as such. POST /v1/decide and POST /v1/messages are engine-only endpoints, not automatically proxied by the Panel. See Panel API and Embeddings.

Control reference