Multi-tenancy
How Tanitar selects your tenant, isolates its data and handles dedicated storage failures.
Every organizer has one tenant identified by accountId. Tanitar derives that tenant from the
credential that authenticated the request:
- an API key for calls from your backend;
- an organization session for dashboard calls;
- a Player context for player calls.
Do not send a tenant identifier in a request body, query parameter or path. Caller-supplied values do not select the tenant.
Storage options
Most tenants use shared storage. Every record, index, read and write remains scoped to its
accountId.
Plans with dedicated storage use a database supplied and operated by the organizer. The same public API applies to both storage options, so switching storage does not change your integration.
A dedicated tenant never falls back to shared storage. If its database or connection configuration
is unavailable, Tanitar returns 503 instead of reading from or writing to another location.
What this means for your integration
- Keep tenant credentials separate. Do not reuse an API key between organizers.
- Treat
403as a final authorization or ownership refusal for that request. - Treat
503storage and access-state errors as temporary. Retry them according to your normal backoff policy. - Use opaque player identifiers. A
playerIdis meaningful only inside the tenant resolved from the credential. - Expect tenant isolation to apply to API calls, scheduled work, messages, webhooks, usage records and audit records.
See Authentication for credentials and Errors for the common error envelope.