Docs
Authentication
One bearer token, a fixed set of scopes, and a tool list that shrinks to match. Tokens are minted in the client area and nowhere else.
Bearer tokens
Every authenticated request carries Authorization: Bearer inl_live_…. There is no
session, no cookie and no signing step. The token identifies the account; the scopes on it decide
what the request may do.
Tokens are stored as a SHA-256 hash, never in plaintext, and the secret is shown to you exactly once — on the screen straight after creation. Nobody, Inleed included, can recover it afterwards.
The public catalogue is the one exception: product and domain pricing answer without a token at all. Everything that touches an account needs one.
Creating a token
Tokens are minted in the client area and nowhere else — Menu → API access → Create token. There is no endpoint that creates a token, so a leaked token cannot mint a second one or widen its own scopes.
-
Name it
A label only you ever see, in the client area's token list — Claude desktop, CI deploy. Name it after the thing holding it, so revoking the right one later is obvious.
-
Pick the access
Read-only (recommended) grants read:* — every read endpoint and every read-only tool, and nothing that can change anything. Full access grants every scope in the picker. Custom lets you tick scopes one at a time; each checkbox shows the raw scope name used in these docs, so what you tick is what you read about below.
-
Decide about money
Allow spending money is its own checkbox, off by default, and offered only alongside Full access and Custom. It adds write:billing. A read-only token can never carry it.
-
Set an expiry
30 days, 90 days (the default), 1 year, or no expiry. Shorter is safer, and minting a replacement costs nothing. An expired token returns
401 token_expired. -
Restrict it to an IP, optionally
One address or CIDR range per line —
203.0.113.4,198.51.100.0/24. IPv4 and IPv6 both work. Leave it empty to allow any address. Anything arriving from outside the list gets403 ip_not_allowed.
Scopes
Scopes are the whole authorisation model. Dangerous verbs are split out of write: so
that granting the ability to change DNS does not also grant the ability to delete a mailbox or
restore a backup over live data.
The sharp edges require two scopes at once: restore_backup needs
write:hosting and restore:hosting;
delete_mailbox needs write:email and
delete:hosting.
| Scope | What it grants |
|---|---|
| Read access Never changes anything. | |
| read:* | Every read scope at once — the Read-only preset. Grants no write, and can never be combined with the money gate. |
| read:account | Profile, preferences, guest access. |
| read:billing | Invoices, PDFs, billing profiles and the prepaid balance. |
| read:services | Subscriptions: status, renewal quotes, billing cycle. |
| read:orders | Orders and the product catalogue. |
| read:hosting | Inside a hosting account: usage, PHP, cron, SSL, files, logs. |
| read:dns | DNS zones and records. |
| read:email | Mailboxes, quotas, forwarders and delivery tracing — metadata, not message bodies. |
| read:database | Databases, users and sizes. |
| read:files | Directory listings, disk usage and available restore points. |
| read:domains | Registrar-side domain state: expiry, nameservers, contacts. |
| read:support | Tickets and replies. |
| audit:read | The audit log. Deliberately its own grant — reading an account’s activity history is not the same thing as reading its data. |
| Manage Changes configuration. Reversible. | |
| write:account | Profile, preferences, guest access. |
| write:services | Rename, autorenew, cancellation. |
| write:orders | Creating and cancelling orders. Checkout and payment always finish in the client area. |
| write:hosting | PHP version, SSL issuance, cron, hosting-level settings. |
| write:dns | Create, update and delete DNS records. |
| write:email | Mailboxes, passwords, quotas, forwarders. |
| write:database | Databases and database users. |
| write:files | File operations inside the hosting account — archive, move, delete. |
| write:domains | Registrar-side changes, including nameservers. |
| write:support | Opening a support request on the account’s behalf. |
| sso:hosting | Single-use DirectAdmin and phpMyAdmin login links. |
| Servers (VPS) Split finely — power, console and rebuild are each their own grant. | |
| read:vps | VPS list and detail — power state, specification, disks, templates and ISO library. |
| write:vps | Resetting the root password. That is currently the whole grant; it is confirmation-tier. |
| power:vps | The power switch — start, stop, reboot. Split from write:vps so a token can manage a server without the power to take it down. |
| console:vps | Opening a VPS console session. A console is root access, so it is its own grant. |
| read:network | Inleed network information — IP ranges and addresses, transit and peering status, licences. |
| Sensitive Irreversible, or moves an asset off the account. | |
| contents:email | Reading the contents of a mailbox — message bodies, not just the metadata read:email covers. Always required alongside read:email, and not yet selectable in the client area’s token form. |
| transfer:domains | Starting an outbound domain transfer — the one operation that moves an asset off the account. |
| restore:hosting | Restoring a backup over live data. Required alongside write:hosting. |
| delete:hosting | Deleting a mailbox or another hosting resource. Required alongside the matching write scope. |
| shell:hosting | Running shell commands on a hosting account as its own user over SSH, and enabling the assistant's SSH key for that. The customer approves the key once. |
| write:payment_methods | Stored payment methods, and paying an invoice with one. Every charge still ends in a human confirmation link. |
| The money gate Its own checkbox, off by default, and never part of Read-only. | |
| write:billing | The money gate. Every operation that can create a charge requires it — renew, upgrade, pay, order, change billing cycle. Withhold it and nothing on the token can spend. |
Reads and writes are asymmetric on purpose: list_services needs only
read:services, while reading inside a hosting account needs
read:hosting. Give an integration the narrowest pair that does its job.
The money gate
write:billing is the single scope that gates spending. Every operation that can create a charge requires it — including several that look like configuration changes: renewing a service, changing a billing cycle, upgrading a plan, cancelling early. Withholding that one scope neutralises the entire spend surface, with no other change to the token.
Even with it granted, nothing charges silently: money operations return a confirmation link a human opens in the client area. See Confirmations.
Absent beats denied
On the MCP side, a tool your token has no scope for is not refused — it is not listed. It never enters the model's context, so it cannot be talked into calling it. Mint a read-only token and the assistant genuinely has no way to change anything, because no tool that changes anything exists as far as it can see.
On the REST side the same rule shows up as a 403 insufficient_scope that names the
scope you are missing — see Errors.
The /mcp/k/ fallback
Claude's and ChatGPT's custom-connector dialogs cannot attach an Authorization header.
For those clients only, the token can travel in the path:
https://mcp.inleed.com/mcp/k/{token}.