Panel API

Use the API workbench at /rust/api to locate registered operations, select a route, generate copyable command-line, Python and JavaScript examples, inspect its schema and send an authorized test request. The separate OpenAPI browser is /rust/api/openapi and the machine-readable description is GET /api/openapi.json (OpenAPI 3.1).

Connect safely

1. Open API workbench and read Base URLs. Read gateway URL and availability queries GET /api/gateway/connect. The response's base_url is the compatible client base, ending in /v1.
2. Open Authentication and follow Access and API keys. In multi-user mode create a key; use it only over a protected connection. The key is shown at creation, not on the inventory page. Automation tokens can be scoped; check x-lexipanel-scope and x-lexipanel-role on the operation in OpenAPI. A scoped token cannot mint or rotate credentials even if its scope is broad.
3. Open Endpoint catalog and expand Browse every endpoint (generated from route registration). Choose an endpoint to view its examples. Administrators can also choose Method and endpoint and press Generate examples. Copy a command-line, Python or JavaScript sample. Set PANEL_URL to the Panel origin (without /v1) and PANEL_TOKEN to the Access-issued secret. Do not paste the secret into the workbench.
4. An authorized administrator may use In-page tester, supply JSON body for POST, and press Send test request. The tester calls the registered route handler with the original authenticated caller. Only allowlisted operations are enabled; credential changes, file operations and engine-only routes are examples-only. A test checks the exact selected route against both the allowlist and the caller’s role and token scope before calling its registered owner.
5. Use View OpenAPI document to inspect operations, required roles and scopes. Machine-readable document exposes the full schema. The preview bounds content and hides credential-like values. Some operation request schemas are intentionally generic: fill required fields from the matching operation contract before sending.

Supported surfaces and their limits

OpenAPI browser uses the same owner as GET /api/openapi.json, not a copied static route file. Viewer sessions can inspect permitted read-only information but never receive the administrator workbench test forms. Native guides check each prerequisite and each action against the same route-level authorization used for direct requests. Every selectable Panel native operation comes from route registration. The catalogue also distinguishes explicitly documented HTTP-dispatch and engine-only operations. The tester refuses unsupported or privileged replays instead of guessing a response.

Guided tasks

Connect existing client (api.existing-client) checks GET /api/gateway/connect, GET /api/openapi.json, GET /v1/models, then links back to the workbench for manual client setup. It does not claim that an empty inventory means inference works.

Typed decision from script (api.typed-decision) obtains the profile list from GET /api/decisions, requests a Profile ID and Decision state, then sends the typed payload to POST /v1/decisions. It reports the real refusal if no validated active profile exists. These guides are administrator-only. They do not mutate configuration; the manual setup step is not automatically marked complete, so no undo is needed.

Other API guides

See Compatible clients, Messages, Typed decisions, and Embeddings.

Control reference