The API left beta on the second of July. It shipped inside platform revision 5.4 in June, ran as an invite beta from February with just over four hundred accounts on it, and has not changed shape since April. Versioned, documented, and covered by the same availability commitment as the panel.
Calling it late would be generous. The reason is not mysterious: an interface sitting on top of a provisioning system that needed three and a half minutes to build a server would have been an interface for polling a spinner. We rewrote the queue first, in 2025, and the ordering was deliberate rather than lucky.
What it does
| Group | What you can do | Notes |
|---|---|---|
| Instances | Create, resize, rebuild, snapshot, restore, destroy | Resize up is live, resize down needs one reboot |
| Images | List the OS catalogue, register a custom ISO by URL | Custom ISO installs are still manual and still slow |
| Networking | Add IPv4, edit reverse DNS, request an IPv6 /48 | Delegated, never proxied |
| Filtering | Read attack events, push layer-7 rules on DDoS Pro | Base filtering has nothing to configure |
| Billing | Read balance, list invoices, open a top-up invoice | No card fields, because there are no cards |
| Events | Poll the event log or register a webhook | Signed with a per-account secret |
Everything is JSON over HTTPS, and every object the panel can show you is an object the API can return. There is no tier of functionality reserved for the web interface, which is a promise that costs us something: the panel now consumes the same public endpoints you do, so a broken API is a broken panel and we find out immediately.
Authentication
Tokens are created in the panel, scoped, and shown exactly once. No password authentication, no session cookies, no redirect to an identity provider we would then have to trust with something we have gone to considerable trouble not to collect.
A token carries a scope of read, write or billing, an optional restriction to a single site, an optional restriction to a list of instances, and an expiry that you set. Sixty days is the default. Tokens can be revoked individually and the revocation is effective at the edge within two seconds, which matters more than it sounds when a build server gets rebuilt by somebody who did not know what was on it.
Because an account here is an email address and a password hash, there is no customer object to fetch. The API has no name field, no address field, no company field and no tax field, for exactly the reason the sign-up form does not.
Rate limits, idempotency, errors
Six hundred reads a minute and sixty writes, counted per token rather than per account, so one noisy script cannot starve the rest of your automation. Limits are returned in headers on every response, including successful ones.
Every write accepts an idempotency key. Retry a create with the same key and you get the original instance back rather than a second one billed alongside it. This is the single feature that beta testers thanked us for most, which tells you something about how the rest of the industry handles a timeout during provisioning.
Errors are a documented machine code, one sentence a human can read, and a request identifier. Paste the identifier into a ticket and support can see the same request you saw, without asking you to reproduce it.
What it deliberately does not do
- No fiat, ever. Billing endpoints read your balance and open a top-up invoice. Settlement stays with OxaPay and the chain you chose, exactly as described on the payments page.
- No sub-accounts or roles. Requested constantly. Not built, because the obvious implementation means holding a structure of who-works-for-whom, and we would rather ship scoped tokens that expire and let you keep your org chart to yourself.
- No autoscaling. Instances are dedicated cores on real silicon, not a pool we can conjure from. You can create and destroy on your own schedule; we are not going to pretend an elastic abstraction sits underneath.
- No SDK matrix. One reference client, and plain HTTP as the contract. Six half-maintained language bindings would age worse than the documentation.
What we would like broken
The beta found nine bugs worth fixing, three of which were ours in an interesting way and six of which were the documentation lying. If you find a tenth, the abuse of a rate limit is fine and expected during testing, and support would rather have the request identifier than a screenshot.
Reference is at the docs. The changelog for revision 5.4 lists the seven endpoints that changed shape between February and April, and those are the only breaking changes there will be inside version one.