Developer access
Everything the console does, you can do from code.
The Sarpius API is public and documented: 72 paths, 98 operations and 20 OAuth scopes, published as OpenAPI. Build against it, drive it from your CI, or let an AI assistant operate your Project. Same permissions whoever is calling.
There is no charge per API call. You pay for what the calls create.
Start here
Get a token, make a call.
Two credentials, depending on who is calling. Both carry scopes, and both are refused the same way when they are wrong.
A person, or an app on their behalf
Standard OAuth2. Register a client, send the user through the authorize step, exchange the code for a token, and refresh or revoke it later. Introspection tells you what a token still carries.
Your CI, with nobody watching
An API key on your account. Create it, use it, delete it when the pipeline is retired. No browser step in the middle of an automated flow.
curl -H "Authorization: Bearer $TOKEN" \
https://sarpius.eu/api/v1/projectsResponse, no valid token:
401 {"message":"Invalid token"}Both of those first two are public. You can read the contract before you have an account.
Three ways in
Same API, same permissions, whoever is calling.
Your own code
OpenAPI describes every endpoint, so a client generates itself. Projects, components, deploys, databases, storage, domains and the wallet are all in the same document.
Your CI
A push is already the deploy, but when you want to drive it yourself the operations are there: trigger a deploy, read its log, roll back, start and stop.
An AI assistant
Connect Sarpius over MCP and an assistant works the Project directly. Every tool is bound to a real API operation, so it cannot reach anything the API does not already expose.
In practice
From an empty account to a running app, without opening the console.
- Create a Project.
- Connect a repository, or start from a template.
- Create a database and link it to the component that needs it.
- Set the variables for each environment.
- Add a domain and let the certificate be issued.
- Deploy, and read the build log as it runs.
- When you are done, remove all of it again.
Guardrails
The interesting part is what it will not let you do.
Opening a platform to scripts and agents is only worth anything if the limits are real. Each of these is in the code, not in a policy document.
Scopes, not a master key
20 scopes, and a token carries only what it was issued. Reading an app and changing how it builds are deliberately different permissions.
Secrets stay secret
Environment values come back redacted to anything that is not a browser session. An agent sees the shape of your configuration and never the values.
Deleting still asks for your second factor
A token cannot remove a Project or a component on its own. With two-factor on your account the call is refused until you supply the code.
Rate limits apply to everyone
Every caller gets a budget per address and a second one per credential on top. An automated client cannot outrun a human one.
Build commands are their own permission
The build fields run verbatim with your decrypted secrets in the environment, so they sit behind a scope of their own that no previously issued token holds.
You can undo what you create
Everything a token can create, a token can also remove: Projects, components, domains, databases, buckets. A creation path with no teardown is a ratchet, and it bills real money.
Start with the reference.
The OpenAPI document, the scope catalogue and the MCP connection guide are all in the docs.