Skip to main content
Splendor uses two pieces of identity on every request:
  1. A bearer token in the Authorization header that identifies you.
  2. A tenant header, X-Splendor-Tenant-Id, that selects which workspace you are acting in.
You get both values from the console. Treat the token as a secret: never embed it in client-side code or commit it to version control.

​
Two kinds of API key

Most of the time a token acts within one tenant — that’s a tenant key (spltk.v1.…), which you mint from the console’s API Keys panel (or POST /v1/admin/api-keys). It’s all you need for everything in these guides. If you’re building a product on Splendor and need to create and operate many tenants — say one per end-customer — you use a platform key (splpk.v1.…) instead. A single platform key provisions tenants and acts inside any of them by naming the tenant in the header. See Build a platform. Both are shown once, and minting either is the one action that requires a human. It’s not about the request method — you can POST it — it’s about which credential is allowed: key creation rejects API keys (both tenant and platform keys get a 403) and accepts only a signed-in admin’s console session. So your first key always comes from a person in the browser. Everything after that authenticates with the key, so a script — or a coding agent — can do the rest.

​
The tenant header

A token can grant access to more than one tenant. The X-Splendor-Tenant-Id header tells Splendor which one this request applies to, and the API enforces that the token actually has access to it. The header is required on every endpoint except two:
  • GET /v1/me — returns your identity and the tenants you can access, so it runs before you have chosen one.
  • The platform endpoints (/v1/platform/*) — these manage your fleet of tenants rather than acting within a single one (see Build a platform).
Requests that omit the tenant header where it is required return 400. Requests that name a tenant your token cannot access return 403.

​
Discover your tenants

Call /v1/me to see who you are and which tenants you can select. Use the tenant_id values it returns as your X-Splendor-Tenant-Id.
Response

​
Roles

Within a tenant, read and query endpoints are available to any member. Operations that create, change, or delete data — managing sources and connectors, editing detections, deleting datasets, triggering reindexes — require an admin role. (Splendor staff have their own internal operations endpoints, separate from everything documented here.) See Roles & permissions for the full breakdown of which operations require which role, and Plans & RBAC for how role enforcement is enabled.

​
Responses to expect

For the full error model and codes, see Errors.