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

# Platform organization

> One organization on SideNet may create other organizations and share what it builds with them — for a product that onboards its own customers onto SideNet.

Most organizations on SideNet are one company with one API key. A product
built *on* SideNet — a vertical app that gives each of its customers their own
agents, workflows and dashboards — needs one more thing: a way to create an
organization for each customer, hand that customer's backend its key, and
keep the pieces every customer shares in one place.

That is the **platform organization**: a single org flagged by SideNet
(`orgs.is_platform`, exactly one row). The flag grants two things and nothing
else.

## What it can do

**Create organizations.** A key of the platform org issued with the scope
`orgs:create` may call `POST /v1/orgs`. The new organization is a normal
organization in every respect; the response carries its API key **once**.

**Share what it owns.** Tool providers, workflows and skills owned by the
platform org carry a share scope — `private`, `platform_created` or `public`
— that decides which organizations see them read-only. See
[Shared platform providers](https://sidenet.ai/docs/connecting-your-api.md#shared-platform-providers).

## What it cannot do

The platform org has **no reach into the organizations it creates**. There is
no header that lets its key act as another org, no route that reads another
org's users, threads or spend. Working inside a created org uses that org's
own key — the one shown at creation. A leaked platform key can create junk
organizations and read *their* keys; it cannot touch an existing one.

The model is flat on purpose: no organization has standing access to another.

## Creating an organization

```bash theme={null}
curl -X POST https://api.sidenet.ai/v1/orgs \
  -H "Authorization: Bearer PLATFORM_KEY_WITH_ORGS_CREATE" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Hotel Group X", "website": "https://hotelgroupx.example" }'
```

```json theme={null}
{
  "org": { "id": "2b9d7c31-…", "name": "Hotel Group X", "status": "live", "created_at": "…" },
  "api_key": "sk_…"
}
```

Store `api_key` where your backend keeps secrets. It is the new org's
"SideNet Studio" key — the same key the Studio would have issued — and it is
not shown again. From here your backend uses it exactly as any customer uses
theirs: to create the org's tool providers, users and schedules, and to mint
session tokens for its people.

Every org created this way is flagged **created by the platform**, so whatever
the platform org shares with scope `platform_created` is visible in it from
the first call.

`status` defaults to `live`; pass `"status": "demo"` for a demonstration org.

## Listing and suspending

`GET /v1/orgs` lists the organizations the platform created, with their
status. Keys are never listed.

`POST /v1/orgs/{id}/suspend` parks an organization: its API keys stop
authenticating and every session minted from them stops resolving. Nothing
is deleted — agents, threads and configuration stay as they are — and
`POST /v1/orgs/{id}/resume` sets it back to `live`. Both apply within the
auth cache window, up to five minutes. The platform org itself cannot be
suspended through this route.

## Getting the scope

The `orgs:create` scope is set on a key by SideNet, on request, for the
platform org only. An ordinary key of the platform org — the Studio key
included — answers `403` on every route of this page.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.