Skip to main content
A tenant is a workspace. Every dataset, source, view, export, and search result belongs to exactly one tenant, and the API never lets data cross that boundary.

How a tenant is selected

Each request carries the X-Splendor-Tenant-Id header. Splendor verifies that your token has access to that tenant before doing anything else. A single token can reach multiple tenants — GET /v1/me lists them — but one request only ever acts within the one you name.

Isolation guarantees

  • Queries are tenant-scoped. A search only ever reads datasets in the selected tenant. There is no cross-tenant query.
  • Handles are tenant-bound. A search_id, view_id, cursor, or export belongs to the tenant that created it. Presenting a handle under a different tenant fails closed.
  • Records carry their tenant. Every stored record records its tenant_id in provenance, so isolation holds at the data layer, not just the query layer.
A handle created in one tenant cannot be read from another, even with a token that can access both. Re-create the search or view under the tenant you intend to use.

Building a platform on Splendor?

If you are putting Splendor underneath your own product and each of your customers has data that must stay isolated, give each customer its own tenant — never a shared tenant partitioned by dataset. See Build a platform on Splendor for the model and Provision tenants for your customers for the API.