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.

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.

This page as Markdown: /docs/platforms.md