> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fourdos.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Tenants

> Every organization is an isolated tenant, with multi-tenancy support for multi-team organisations

## Organizations are tenants

Your organization is a **tenant** of 4D. Your API key is bound to it, your
data lives inside it, and isolation is enforced at the database layer with
row-level security - not just in application code. There is no cross-tenant
read path: a partner API call can only ever see its own organization's rows.

Everything in these docs is scoped by that boundary: your
[members](/concepts/members), your [events](/concepts/events), your
[XP economy](/concepts/xp), and your members' [consent](/concepts/consent)
records all belong to your tenant.

## Multi-tenancy for multi-team organisations

4D is multi-tenant by design, and that extends to partners who are themselves
more than one team. A multi-team organisation - a club group, a league, a
federation with several sides - can run each team as its own tenant: separate
API keys, separate member rolls, separate XP economies, tiers, and consent
scopes, with no data bleed between them.

Because identity is two-level, this stays friendly for the fan: one person
who follows two of your teams is still **one 4D user** holding a membership
in each tenant, with a single wallet and sign-in. Each team sees only its own
membership; the platform handles the rest.

## Bespoke integrations

The standard surface - the [REST API](/api-reference/overview), the
[engagement SDK](/sdk/engagement-sdk), and
[bulk import](/walkthroughs/migrate-existing-members) - covers most
integrations. When you need a private event surface, a partner admin can create and publish a private module, then install it for the owning organization. See [Publish a private module](/walkthroughs/publish-a-private-module) for the complete REST path.

A private module has an owning organization. It is visible and installable only to that organization, while a module without an owner is a platform or vendor module visible to every organization. Module authoring uses an admin session; an `org_` key authenticates a service identity for partner reads and cannot publish a module or mint another key.

The module declares its native event types and payload schemas. Canonical event types belong to the platform. At publish time, the manifest must fit the platform module contract; a manifest that does not fit is rejected and remains in draft. During ingest, native payloads and their mapped canonical payloads are checked again before a canonical event is emitted.