Developers
The API exists. The public reference does not — yet.
Everything on this platform — the storefront, the cart, the panel — already talks to one API. What we have not done is publish it: there are no customer tokens and no reference documentation today, and we would rather say so than sell you a screenshot.
Today
What is actually true right now.
The platform is API-driven internally. When you resize a server or take a snapshot from the panel, the panel is making the same calls a public client would make — there is no second, privileged path. That is a deliberate design choice, and it is what makes publishing the API a matter of documentation and token issuance rather than a rebuild.
What does not exist yet: API keys you can create yourself, a published reference with schemas, and the stability promises that make an API worth building against. Until we can put version and deprecation policies in writing, we are not handing out tokens — an API that changes under you is worse than no API.
If your workflow needs programmatic provisioning today, tell us what you are building via the enquiry form. Interest genuinely shapes the order we build in, and early access will start with the people who asked.
Planned surface
What the public API will cover.
These are the capabilities the internal API already has and the public one will expose. Planned means planned — none of it is callable by customers today.
- Server lifecycle
- Create, resize, rebuild, snapshot, power-cycle and destroy — every operation the panel performs, callable from your own code.
- Live catalogue
- Plans, regions and images as data, with the same prices the storefront shows — including your partner discount where one applies.
- Domains and DNS
- Search, register and manage records from the same registrar integration the site uses.
- Usage and billing
- Hour-by-hour metering you can read programmatically — the numbers you would need to rebill your own customers.
- Webhooks, not polling
- Lifecycle events pushed to your endpoint and signed, so your systems react instead of asking.
- Scoped tokens
- Read-only, provisioning-only or full-access keys, revocable instantly, with per-token audit logs.
Principles we are building to: plain REST with meaningful status codes, idempotency keys on mutating calls, cloud-init user_data at create time, rate limits stated in response headers, and errors that tell you what to do next. Boring by design.
Register interest
Tell us what you would build with it.
A sentence about your use case is enough. You will hear from us when there is something real to try — not a drip campaign.