For most use cases, the
slideless CLI handles the upload flow end-to-end. The CLI command is slideless push [path] --title "..." (the CLI reads slideless.json to decide new-vs-update).Endpoint
Auth
Required scope:
presentations:write.
Request body
Path rules:
path must be deck-root-relative, no .. segments, no leading or trailing slash, no backslashes, no null bytes, ≤ 512 chars.
All hashes must exist: the backend checks every sha256 in files[] against the blob store. If any are missing, the call returns 400 blobs-missing and the manifest is not written.
Example (new presentation):
Response (200)
New presentation (on sessionId)
"default" is created with versionMode: {type: 'latest'}. It’s the only token — mint more with addPresentationToken.
Update (on presentationId)
tokenId/token omitted on update. shareUrl reuses a non-revoked token that follows latest. The bumped currentVersion is now 3; existing tokens on latest see v3 on next load, pinned tokens stay frozen on their version.
Plan caps
See Presentations for the full table.
What happens on the backend
- Validate the request (auth, scopes, ownership, caps).
- Confirm every
sha256infiles[]exists in the blob store — 400 if any are missing. - Compute
nextVersion = isNew ? 1 : currentVersion + 1. - Write
manifests/v{N}.jsonto Cloud Storage (immutable). - Create or update the
SharedPresentationFirestore doc (currentVersion= nextVersion). - Clean up the upload session (if applicable).
Errors
Next
- POST /addPresentationToken — mint more named share tokens.
- POST /setTokenVersionMode — pin a token to a specific version.
- GET /getSharedPresentationInfo — inspect every token’s view count.