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

# Multi-tenant data model

> Multi-tenant auth is built around two core entities: Organizations and Members.

## Key objects

<Columns cols={2}>
  <Card title="Organization object" icon="building" href="/api-reference/b2b/api/organizations/organization-object" horizontal>
    A tenant in your app, typically used for your top-level customers.
  </Card>

  <Card title="Member object" icon="user" href="/api-reference/b2b/api/members/member-object" horizontal>
    An individual end user's account within an Organization.
  </Card>
</Columns>

## Overview

In multi-tenant applications, a business account owner (organization) is in control of who (members) can access their instance, how they authenticate, and what they can do within that instance. The organization is ultimately in control of all of the end users who access their instance.

Members are identified by their email:

```mermaid theme={null}
---
config:
  title: Relationship model between Orgs & Members
  layout: elk
  elk:
    mergeEdges: true
---
erDiagram
  p["Multi-tenant project"]

  o1[Organization] {
    string id "org-001..."
    string slug "acme"
  }

  o2[Organization] {
	string id "org-002..."
	string slug "stytch"
  }

  m1[Member] {
    string id "member-583..."
    string email "ada@stytch.com"
  }

  m2[Member] {
    string id "member-9a1..."
    string email "ada@stytch.com"
  }

  m3[Member] {
    string id "member-30w..."
    string email "baker@stytch.com"
  }

  p ||--|| o1 : ""
  p ||--|| o2 : ""
  o1 ||--|| m1 : ""
  o2 ||--|| m2 : ""
  o2 ||--|| m3 : ""
```

### Unique identifiers

Organizations are uniquely identified by:

* `organization_id`
* `organization_slug`

Members are uniquely identified by:

* `member_id` is unique across all Organizations
* `email_address` is unique within the Organization, but can link a member across Organizations

### Organization-specific configurations

Each Organization has its own set of configurations, allowing your customers control over their own auth requirements. Organization-specific settings include, but are not limited to: approved auth methods, JIT provisioning, SSO connections, MFA policies, custom metadata, and more.

***

## Hybrid model

If you have a mix of business customers and individual end users, **we recommend using multi-tenant auth and creating an Organization behind the scene for each individual user "tenant"** in order to allow these single-player accounts to seamlessly upgrade and add potential collaborators in the future.

***

## Don't need multi-tenancy?

Use [consumer auth](/consumer-auth/data-model) if you don't require Organizations or multi-tenancy.