Skip to main content

​
VegaLake API reference

The generated reference publishes customer-facing operations from four canonical backend contracts:

​
Authentication

Use the security requirements shown on each operation:
  • Bearer authentication represents an authenticated user session/token.
  • API key authentication represents an authorized service principal where the operation supports it.
Do not send both by habit. Choose an accepted scheme and give that identity the minimum required permissions. Never embed tokens or API keys in source code, documentation, query strings, or logs.

​
Tenant scope

Most customer resource paths include:
The IDs must describe the same tenant boundary. IAM and organization-security routes may stop at org_id; authentication routes can be unscoped. A valid credential does not override a mismatched scope or missing resource permission.

​
Requests and errors

Send JSON bodies with Content-Type: application/json when a body is defined. Use required fields, enums, formats, and cross-field rules from the generated schema. Pagination parameters and response envelopes vary by operation; do not add undocumented pagination. Handle non-success responses by HTTP status and the documented error object. Preserve a request ID for support, but redact authorization headers, credentials, backup codes, connection secrets, and secret values.

​
Publication boundary

These specs are generated from backend OpenAPI snapshots and filtered deterministically. They intentionally exclude /internal/*, platform-operator admin-* operations, BFF/session plumbing, Auth-provider internals, node-type administration, health endpoints, and the private cluster-orchestrator control plane. VegaDB has no public API contract while the product remains in preview.