API keys, permissions and scopes

Sending the key

Send the key in the Authorization header as a bearer token. A request without one, or with a key that is wrong, expired or deleted, gets a 401.

Keys made from October 2026 start with sdevc_. Older keys start with ptlc_ and keep working exactly as before. The first 16 characters identify the key, and the rest is the secret.

Authorization: Bearer sdevc_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Creating a key

In the panel, open Account, then API keys, then Create. Give the key a name you will recognise later, such as the script that uses it, and choose what it may do. The secret is shown once, when the key is made: copy it then. If you lose it, delete the key and make another.

Keys can only be made, changed and deleted in the panel, never through the API, so a leaked key cannot make more keys or give itself more access.

Limiting a key to some servers

A key can be limited to a list of servers. It then cannot see or touch any other server on the account, and a request for one gets a 404, as if the server did not exist.

Server permissions

A key can also be limited to a set of permissions, the same ones you give subusers: control.start, control.console, file.read and so on. Each endpoint on these pages names the permission it needs, and a request without it gets a 403. GET /permissions lists every permission there is.

The panel offers presets so you need not pick from the whole list: full access, bot control (power and console) and read-only monitoring. A few things only a server's owner can do, such as deleting it and linking a Git repository, and a key limited to some permissions cannot do those at all.

Account scopes

What a key may do with the account itself is set separately, by scope. account.read reads the account and its activity. servers.create creates free servers. databases.read and databases.write list and manage databases. billing.read reads plans and subscriptions. billing.purchase orders paid servers and changes or refunds plans.

A key with full access has every scope except billing.purchase, which is off until you turn it on for that key. A key limited to some servers or permissions has no scopes unless you give it some.

A key that may buy can start 2 orders in any 24 hours, and every order it starts is emailed to you, so a leaked key cannot run up a bill in secret.

IP addresses and expiry

A key can be limited to the IP addresses (or ranges) your script runs from. Requests from anywhere else get a 403, even with the right key.

A key can be set to expire after 7, 30 or 90 days. You are emailed three days before, and once the date passes the key stops working and is deleted. Keys that are never used for a long time are warned about and removed too.

Changing a key

Everything about a key except its secret can be changed later in the panel: its name, servers, permissions, scopes, IP addresses and expiry. Taking access away is instant. Giving a key more access than it had asks for your password first.

Keeping keys safe

Treat a key like a password. Keep it in an environment variable or your host's secret store, not in your code, and never commit it to Git. Give each script its own key so you can delete one without breaking the others. If a key leaks, delete it in the panel at once; nothing else is needed.