> ## 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.

# Share tokens

> Per-recipient links with independent view counters and granular revocation

## 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](/concepts/versioning)** — `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:

| Scenario                                        | What you do                                                    |
| ----------------------------------------------- | -------------------------------------------------------------- |
| Send a deck to two prospects, see who's looking | Create one token per prospect, watch `accessCount` for each    |
| One contact leaves their company                | Revoke their token — others keep working                       |
| Run an A/B test on send copy                    | Different tokens in different emails, compare `lastAccessedAt` |
| Public version + private version                | One 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>`.

<Info>
  **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](/concepts/collaboration) and the `invite` command.
</Info>

<Info>
  **Emailing a deck mints one token per recipient automatically.** When you use [`slideless share-email`](/guides/sharing-via-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.
</Info>

## 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

| Field                    | Type                                              | Description                                                                   |
| ------------------------ | ------------------------------------------------- | ----------------------------------------------------------------------------- |
| `tokenId`                | UUIDv7 string                                     | The internal ID (stable, used for revocation + pinning)                       |
| `token`                  | base64url string                                  | The actual secret in the URL — 384 bits of entropy                            |
| `name`                   | string                                            | Human-readable label (e.g. `"default"`, `"John at Acme"`)                     |
| `versionMode`            | `{type:'latest'}` or `{type:'pinned', version:N}` | Which version this token resolves to. See [Versioning](/concepts/versioning). |
| `createdAt`, `createdBy` | timestamp / userId                                | When and by whom                                                              |
| `revoked`                | boolean                                           | If `true`, the share URL returns 403                                          |
| `revokedAt`, `revokedBy` | timestamp / userId / null                         | Set on revocation                                                             |
| `lastAccessedAt`         | timestamp / null                                  | Most recent view                                                              |
| `accessCount`            | number                                            | Total views via this token                                                    |

## Pin a token to a specific version

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
# 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](/concepts/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.