Session Files

For step-by-step integration flows, start with the Uploading session files guide.

Upload paths

Simple (≤ 50 MB)
Direct to storage (≤ 500 MB)

One multipart call — Sessionboard detects size and MIME type, scans the file, and returns the attached Content object.

POST .../files/upload with multipart field file
Optional form fields: title, assigned_participant_id

Presigned URL flow for larger files or clients that prefer direct-to-S3 upload:

POST .../files — JSON with filename and size_bytes
PUT bytes to data.upload.url
POST .../files/{fileId}/complete

Upload slots

Organizers can define what they ask speakers for as upload slots — Poster, Presentation, Handout — each with its own deadline, accepted file types and file count (Program → Settings → Files → Use upload slots). GET /v1/event/{eventId}/content-slots lists them in the order speakers see them, and every session file carries content_slot_id pointing at the slot it answers, so a poster is distinguishable from a deck without inspecting filenames or MIME types.

Events still on a single file request return an empty slot list and content_slot_id: null on every file. Slot definitions are read-only through the API.

Uploading into a slot. POST .../files and POST .../files/upload accept an optional content_slot_id. Ask GET /v1/event/{eventId}/content-slots?session_id={sessionId} which slots apply to the session, then send the slot’s id with the file. API callers act as the organization, so no slot deadline applies and a file may still be attached without a slot — but a slot you name is a contract: it must be active, apply to the session, accept the file’s declared type and have room under its max_files, or the request answers 400 naming the slot. The file’s type is derived from the slot’s content_type.

Scopes

Action	Scope
List upload slots	`read:sessions`
List files	`read:sessions`
Upload / create / complete / replace / update / delete	`write:sessions`

Endpoints

List upload slots

GET /v1/event/{eventId}/content-slots

Simple upload

POST /v1/event/{eventId}/sessions/{sessionId}/files/upload

List session files

GET /v1/event/{eventId}/sessions/{sessionId}/files

Start direct upload

POST /v1/event/{eventId}/sessions/{sessionId}/files

Complete direct upload

POST …/files/{fileId}/complete

Replace file bytes

POST …/files/{fileId}/replace

Update metadata

PUT /v1/event/{eventId}/sessions/{sessionId}/files/{fileId}

Response shape

File objects use the Content schema (id, url, title, filename, size, mimetype, type, label, assigned participant fields, timestamps). Direct-to-storage create/replace responses also include an upload object with url, method, and headers for the presigned PUT.

type is the organizer-facing file type (presentation, handout, poster, holding_slide for slides Sessionboard generated, …) and label is the display label from the session’s Files tab. The list endpoint filters on it:

# Only the generated holding slide(s) for a session
curl "https://public-api.sessionboard.com/v1/event/{eventId}/sessions/{sessionId}/files?type=holding_slide" \
  -H "x-access-token: YOUR_TOKEN"

# Several types: comma-separated or repeated
curl ".../files?type=presentation,handout"
curl ".../files?type=presentation&type=handout"

A generated holding slide keeps the same id when it is regenerated, so a client that cached the file id keeps working; only url, filename, size and updated_at change.