Tenancy

RUO Pro is multi-tenant. Two rules — fail-closed tenancy (tenant resolution never defaults and never trusts request parameters) and credential-carries-ownership (the credential, not the caller, names the tenant) — govern every tenant-facing route.

Fail-closed tenancy

A request’s tenant is resolved from its credential or token claim, never from a request parameter and never defaulted. There is no “default tenant” anywhere in the system.

Credential-carries-ownership

Tenant-facing auth follows one pattern everywhere: API keys are resource-bound rows, hashed at rest, issued against a closed scope allowlist. A key’s scope says “some tenant can do X”; the key row says which tenant. Every tenant-facing route resolves ownership from the credential that made the call — never from a path or body parameter the caller supplied.

This is the same pattern the merchant API (fdk_-prefixed keys) and the storefront’s self-serve /v1/my/* routes both use — see Reference -> Tenant-facing API for the concrete routes.

The one exception — Host-header resolution

The hosted storefront must resolve a tenant from the Host header, which is attacker-influenced request data — on its face a violation of fail-closed tenancy. This is the one exception, and it is fail-closed:

Host header -> verified domain mapping -> tenant

An unknown or unverified host is a hard 404 — no fallback store, no default tenant. The mapping is created only by the domain-verification flow (POST /v1/my/domains, POST /v1/my/domains/:id/verify). A misconfigured DNS entry must never serve one store’s checkout under another store’s domain.