Pricing Install

Developer portal

How to drive this platform from another program: create an application, deploy a compose file to it, and read back the address the result answers on.

This is the contract for a machine consumer โ€” a service that manages applications on somebody's behalf, continuously, with no person at the keyboard for any given call. Everything here is reachable with an API token and nothing else. There is no session, no CSRF, and no HTML in the path.

Page What it covers
Authentication Getting a token, and what it can do
Applications and deploys Create, upload a bundle, set variables, watch a revision
Published ports Asking for a port, or being given one
Reading an address Where a deployed service actually answers

Examples using {{ example:โ€ฆ }} are a test

Any request or response body written as an {{ example:โ€ฆ }} placeholder is not written by hand. It is a fixture under app/tests/contracts/api/, compared byte-for-byte against a live response by the test suite, and this portal renders the same file. A documented example that stopped being true is a failing build rather than a page nobody noticed โ€” the same technique the /health contract already uses after a documented shape and an asserted shape drifted apart for a day.

That means you can copy one of those and expect it to match what you get, down to the null fields. Not every body on these pages goes through the placeholder yet โ€” Applications and deploys still has two hand-typed request bodies with no backing fixture โ€” so treat a body without the placeholder as illustrative rather than asserted.

The shape of the API

Two prefixes, both bearer-token only:

Prefix For
/cli/โ€ฆ Everything a consumer drives: organizations, applications, variables, endpoints
/applications/{slug}/bundle The compose + build-context upload that creates a revision

API Platform's /api also exists โ€” a bearer token reaches it too, since #1418 โ€” but it is a different, JSON-LD/Hydra-shaped surface describing the same resources, not an alternative path to /cli. It exists to be machine-readable (OpenAPI 3, /api/docs) rather than hand-documented, and is what the generated client SDKs below are generated from.

Existing clients

Three consumers already speak the /cli contract, if writing your own is more than you need: the sc CLI, sc-tray (the menu-bar client), and the Terraform/OpenTofu provider (declarative applications, variables, managed services and bindings). None of the three use /api โ€” they predate it, and /cli remains the contract this portal documents by hand.

Client SDKs

Four generated clients for /api โ€” not /cli โ€” one per language, each its own repo:

Language Package Repo
PHP someones-computer/sdk-php (Composer) sdk-php
Go github.com/someones-computer/sdk-go sdk-go
TypeScript @someones-computer/sdk-js (npm) sdk-js
Python someones-computer-sdk (PyPI) sdk-python

Every operation takes the same bearer ApiToken as /cli โ€” see Authentication. /sdks is the public page for these (install snippets, links, one mascot per language); see docs/sdk-generation.md in the main repo for how they're generated and regenerated, and their current rough edges (default-generated method names, not yet published to a package registry).

Base URL and versioning

Every path on these pages is relative to the install you are talking to โ€” https://someones.computer for the public one. There is no version prefix. The contract grows by adding fields; a consumer must ignore fields it does not recognise rather than failing on them, because new ones will appear.