Publishing and versioning | SeatLayer Developer Docs

Understand draft autosave, published snapshots, unpublished changes, and event-pinned inventory.

Publishing creates a stable chart snapshot that can be used for events. Draft editing and live event inventory remain deliberately separate.

Lifecycle

chart-lifecycle.txttext

draft
  └─ Publish ───────────────> published
                                  │
                                  └─ edit draft ──> published_draft
                                                         │
                                                         └─ Publish ──> published

Status	Meaning	Can create an event?
`draft`	Autosaved working document, never published	No
`published`	Draft and latest published snapshot agree	Yes
`published_draft`	A published snapshot exists, with newer draft edits	Yes, from the published snapshot

Events pin a snapshot

This protects seat identity, capacity, booking mode, labels, and buyer trust. Changing an existing event’s chart is a separate inventory migration decision with its own safety rules.

Publish safely

Validate the draft

Resolve duplicate labels, malformed geometry, missing categories/focals, and accessibility issues.

Review buyer evidence

Preview 2D, 3D where enabled, mobile, tiers, GA, tables, and accessible inventory.

Publish

Create the immutable snapshot. Embedded Designer sessions require canPublish: true; otherwise publication returns 403.

Create or update events intentionally

New events use the new snapshot. Existing events remain pinned until an explicit supported refresh/migration is chosen.

Republish versus duplicate

Republish updates the source chart’s published snapshot for future use.
Duplicate creates an independent draft chart, even when the source was published.
Create event materializes inventory from the selected published snapshot.
Edit event inventory is an operational action, not chart draft editing.

Platform automation

Platforms can follow the same lifecycle with server credentials:

create or duplicate chart
→ update the versioned draft
→ validate
→ POST /v1/charts/:id/publish
→ POST /v1/events

Use an Idempotency-Key for provisioning mutations so retries do not create duplicate resources. Keep the chart id, published version/evidence, and event key on your tenant records.

Change-management checklist

Draft autosave is not treated as publication.
Validation and buyer preview pass before publishing.
The publisher has explicit permission.
Teams understand which existing events remain pinned.
Automation uses idempotency keys and records resource ids.
Duplicate charts are reviewed and published independently.
Any existing-event refresh has a capacity/identity migration plan.

Continue with platform integrations or going live.