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

# Partner domains

> Every workspace lives on its own subdomain — the subdomain is the partner boundary.

Every Traddal workspace gets its own subdomain, and that subdomain **is** the
partner boundary:

| Host                      | Role                                    |
| ------------------------- | --------------------------------------- |
| `mytraddal.com`           | Marketing / apex — no workspace session |
| `app.mytraddal.com`       | Central sign-in and workspace picker    |
| `{partner}.mytraddal.com` | One workspace **and** its Admin API     |

## The subdomain in API requests

Admin API requests go to your workspace's own host:

```text theme={null}
https://{partner}.mytraddal.com/admin/api/v1/{resource}
```

Replace `{partner}` with your workspace's slug (lowercase letters, digits, and
hyphens). The API verifies that the organization inside your bearer token
matches the workspace the subdomain resolves to — a mismatched token gets a
`403`, even if it's otherwise valid. You can't reach one partner's data
through another partner's domain.

<Note>
  Reserved subdomains — `www`, `app`, `api`, `admin`, `auth`, `static`,
  `assets`, `cdn`, `mail` — are never assignable as partner slugs.
</Note>

## Why a domain per partner?

Pinning each workspace to its own host gives isolation at the transport
layer, not just in application code:

* Dashboard sessions are host-only cookies — a session on
  `acme.mytraddal.com` is physically unavailable to `globex.mytraddal.com`.
* API tokens carry the organization; the subdomain must agree with it.
* Row-level security in the database scopes every query to the organization,
  as a final backstop.