Two key types
Almost everything you do uses an organization key. Admin keys exist for platform-level automation and are not exposed in the dashboard.
How you use it
The recommended path is theslideless CLI. Either approach stores the key in ~/.config/slideless/config.json (mode 0600) and configures every subsequent CLI command to send the right Authorization header.
From scratch, no dashboard needed (full guide):
signup-complete creates your account + organization + a cko_ key and saves it as the active profile, all in one call. For an existing account on a new machine, use login-request + login-complete instead.
Paste a key from the dashboard:
slideless use <name>.
If you call the HTTP API directly, send the key as a bearer token:
Scopes
When you create an organization key, you pick scopes:
A key without the relevant scope returns
permission-denied (HTTP 403) from the affected endpoint. Pick the narrowest scope set that fits the use case. A script that only lists decks should use presentations:read only.
Lifecycle
What’s stored, what isn’t
Slideless stores:- A SHA-256 hash of the key (not the raw value)
- The prefix (first 8 chars) for display in the UI
- Metadata: name, description, scopes, organizationId, userId, createdAt, lastUsedAt, expiresAt
Limits
Verifying a key
The simple way is the CLI:✓ API key valid and exits 0 on success, nonzero on failure. Convenient for CI and troubleshooting.
If you need to call the HTTP endpoint directly, see POST /verifyApiKey.
Errors you might see
Operational guidance
- Treat keys as secrets. Don’t commit them to git, don’t paste them in chat, don’t put them in client-side code.
- Use one key per integration. Easier to rotate, easier to attribute usage.
- Set
lastUsedAtreminders. If a key hasn’t been used in a long time, it’s a candidate for revocation. - Prefer scoped keys over admin-style “do anything” keys. Even if the dashboard only offers
presentations:readandpresentations:writetoday, picking the minimum reduces blast radius later.