A personal access token lets a script, a CI job or an AI assistant work with your SashiDo apps as you, with only the permissions you give it. It is the safe alternative to sharing your password or an app's master key:
- Scoped: it can do only what you chose, e.g. read and nothing else.
- Limited to apps: all your apps, or only some.
- Expiring: in 7, 30, 90 days or a year, or never.
- Revocable: one click in the dashboard, effective immediately.
- Audited: every change it makes is in your account's Activity, with the token's name and the client that used it.
Create a token
- Open the dashboard › Account › Access Tokens › Create token.
- Name it after where it will live, e.g.
Claude Code on my laptoporGitHub Actions deploy. The name shows in the Activity. - Choose the permissions: Read-only (reads apps, settings, logs and data, changes nothing), Full, or Custom.
- Choose the apps and the expiry (90 days unless you choose otherwise).
- Copy the token. It is shown once: SashiDo stores only a hash of it.
With two-factor authentication on, creating a token asks for a code we email you. We also email you whenever a token is created.
A token looks like sashido_pat_ followed by 36 characters. It ends with a checksum, so a mistyped token is refused before anything is looked up.
Use it
Send it as a Bearer token:
curl https://api.sashido.io/tokens/current \
-H "Authorization: Bearer $SASHIDO_TOKEN"
{
"data": {
"id": "…",
"name": "Claude Code on my laptop",
"scopes": ["account:read", "apps:read", "logs:read", "data:read"],
"appIds": null,
"expiresAt": "2027-02-11T09:30:00.000Z",
"user": { "objectId": "…", "username": "you@example.com" }
}
}
Keep it in an environment variable or your CI's secret store, never in code or a repository.
Scopes
| Scope | Allows |
|---|---|
account:read |
List your apps and their infrastructure, read the Activity (audit log). |
apps:read |
Builds, build logs, deployments and who started them, engines, health, Parse Server versions. |
apps:write |
Create and rename apps; change the engine, scale, high availability and Parse Server version. These can change your bill. |
deploy |
Build, deploy and cancel. |
env:read |
Read environment variables. |
env:write |
Change environment variables. |
settings:read |
Read App Settings (login methods, email, push, Live Queries, API options) and the custom domain. Secrets are never shown. |
settings:write |
Change App Settings and the custom domain. |
logs:read |
Read the app's logs. |
data:read |
Read the schema, objects, cloud code, jobs, push status and webhooks. |
data:write |
Change data and schema, call cloud functions, send push notifications, run jobs, manage webhooks. |
A request needs every scope its endpoint requires. Each endpoint's scope is listed in the API reference.
What a token can never do
Some things stay with you in the dashboard, whatever the scopes:
- create, change or revoke tokens;
- delete apps;
- see billing, payment details or the apps' keys (master, client and REST keys);
- sign in, or use your sessions and two-factor authentication;
- change the engine, scale or high availability of an app you collaborate on but don't own.
Requests made with a token run as you, so the apps' ACLs and class-level permissions apply exactly as in the dashboard.
When a token stops working
A token stops working when:
- you revoke it, or it expires;
- you change or reset your password, unless you turned on Keep after password change for that token;
- the account is suspended.
Requests with it then get 401 with WWW-Authenticate: Bearer error="invalid_token". To revoke every token at once, use Revoke all on the Access Tokens page.
Errors
Errors have a JSON body { "code": …, "message": "…" }:
| Status | Code | Meaning |
|---|---|---|
401 |
300 | The token is invalid, expired or revoked. |
403 |
301 | The token is missing a scope; the message names it. |
403 |
302 | The token isn't allowed to access this app. |
403 |
303 | The endpoint isn't available with an access token. |
429 |
304 | Too many requests: wait for the seconds in Retry-After. |
Each token can make 600 requests per minute. Refused requests (a missing scope, another app) are recorded in the Activity as security events.
See what a token did
Account › Activity in the dashboard shows each change and who made it: you in the dashboard, or a token, by its name. For tokens it also shows the client, such as the MCP server and the assistant behind it (e.g. Claude Code), and, through MCP, the tool. Reads of your data are summarized by the hour; reads of your app's users are recorded one by one. Security events are kept for three years, the rest for a year.
The Activity is also available from the API (GET /activities) and to your AI assistant (get_audit_log).
Good habits
- One token per place it lives, so revoking one breaks nothing else.
- Start with Read-only, and add scopes when a task needs them.
- Limit tokens to the apps they're for, and give them an expiry.
- Revoke a token the moment it might have leaked: a public commit, a shared screenshot, a pasted log.