Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.slideless.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
What a share token is

A share token is the secret embedded in a share URL: 
https://app.slideless.ai/share/{presentationId}?token={shareToken}
A presentation can have many tokens. Each one:
  • Is independently revocable
  • Tracks its own view count and lastAccessedAt
  • Has a name (e.g. default, John Doe, q4-board) for human readability
  • Has a version mode — latest (follows updates) or pinned to a specific version N
  • Is generated server-side as 48 random bytes (384 bits of entropy), encoded base64url

​
Why multiple tokens

A single presentation can be shared with many people, each via their own token, so you can:
ScenarioWhat you do
Send a deck to two prospects, see who’s lookingCreate one token per prospect, watch accessCount for each
One contact leaves their companyRevoke their token — others keep working
Run an A/B test on send copyDifferent tokens in different emails, compare lastAccessedAt
Public version + private versionOne default token, one revocable “guest” token
A fresh push does not create any tokens — the deck starts unshared. Run slideless share <presentationId> to mint the first token (named default unless you pass --name). Add more by calling slideless share <presentationId> --name <label> again, or from the dashboard’s presentation detail page. To inspect every token’s view counter from the terminal, run slideless get <presentationId>.
Share tokens are view-only. They grant read access to the rendered deck at the URL. For editors (someone who should push new versions), see Collaboration and the invite command.
Emailing a deck mints one token per recipient automatically. When you use slideless share-email, the dashboard’s “Share via email” modal, or the share-presentation-email plugin skill, each recipient gets their own named token (name = recipient email). You don’t have to call slideless share manually for each one — per-recipient opens show up under that recipient’s address in the Share links table.

​
Lifecycle

created (revoked=false, accessCount=0)
  ↓
each view: accessCount += 1, lastAccessedAt updated
  ↓
revoked (revoked=true, viewers see 403)
Revocation is permanent in v1 — there is no un-revoke. Revoking one token never affects the others.

​
Anatomy

FieldTypeDescription
tokenIdUUIDv7 stringThe internal ID (stable, used for revocation + pinning)
tokenbase64url stringThe actual secret in the URL — 384 bits of entropy
namestringHuman-readable label (e.g. "default", "John at Acme")
versionMode{type:'latest'} or {type:'pinned', version:N}Which version this token resolves to. See Versioning.
createdAt, createdBytimestamp / userIdWhen and by whom
revokedbooleanIf true, the share URL returns 403
revokedAt, revokedBytimestamp / userId / nullSet on revocation
lastAccessedAttimestamp / nullMost recent view
accessCountnumberTotal views via this token

​
Pin a token to a specific version

# Freeze this recipient on v3 — later updates don't reach them.
slideless pin <presentationId> <tokenId> --to-version 3

# Put them back on auto-update.
slideless pin <presentationId> <tokenId> --latest
Recipients cannot see past versions by URL manipulation — there is no ?v=N query parameter. A latest token sees the current version; a pinned token sees exactly that version. Only the owner, from the dashboard, can browse history. See Versioning for why.

​
Security guarantees

Share tokens are designed to be safe to put in URLs:
  • 384 bits of entropy — far beyond brute-forcing. No rate limit needed for this reason alone.
  • Constant-time comparison — token validation iterates all tokens and uses bitwise XOR to prevent timing attacks. An attacker can’t infer how close their guess was from the response time.
  • Generic 404s — if the token is wrong or the share ID doesn’t exist, you get the same 404 response. There’s no way to enumerate share IDs by probing.

​
What a token does NOT do

  • It doesn’t authenticate the viewer (no login required, no identity checked).
  • It doesn’t expire (in v1 — expiresAt exists in the data model but isn’t enforced).
  • It doesn’t restrict who can view — anyone with the URL can open it. Use revocation when a token shouldn’t be valid anymore.

​
Operational notes

  • Don’t shorten the URL through public link shorteners — they often log clicks and can leak the token.
  • Treat the URL like a password for the deck content. If you wouldn’t email the content directly, don’t email the URL.
  • For high-sensitivity decks that need access control (login, allowlist), Slideless isn’t the right tool today. The share-token model assumes public-with-tracking, not gated access.