# Platforms

If you run a product on 639 Shell (agents for your own customers, for example), a **platform** org
makes an org for each of your customers and works in it by API. The platform tier is set by us:
ask for it.

```sh
curl -X POST .../v1/orgs -d '{"name": "Customer A", "limits": {"machines": 20, "cores": 32}}'   # → {"id": "o_…"}
curl -H '639-Org: o_…' -X POST .../v1/machines -d '{"size": "s2", "image": "ubuntu"}'
curl -H '639-Org: o_…' -X POST .../v1/keys -d '{"name": "customer-a-agents"}'
curl .../v1/orgs                       # each with its machine count
curl -X DELETE .../v1/orgs/o_…         # once it has no machines, IPv4s or VPCs
```

- **Acting in one.** Any `/v1` call with the header `639-Org: <id>` acts in that managed org. Only
  the platform org's owners and admins send it. Over MCP an agent acts in its own org only.
- **Keys for your customer.** A key made with the header belongs to that managed org alone (it
  can't reach your platform org or your other customers), for handing to your customer's agents.
  It works while the person who made it is still an owner or admin of the platform org.
- **Limits.** Each managed org has its own limits (machines, cores, RAM, disk, IPv4s; none above
  your platform's), and all of them together with your own machines stay within your platform's
  limits: an error says "the platform's pool" when that's what's full.
- **Usage and events.** `GET /v1/usage` with the header gives a managed org's usage;
  `GET /v1/events?managed=true` gives your managed orgs' events with your own.
- **Holds.** Suspending or closing your platform org does the same to its managed orgs. A managed
  org can't make managed orgs.