Skip to main content

Publishing

Publishing takes ticketing from a private configuration into a public sale. Once published, attendees can see and buy tickets to the event, and the editing rules tighten to protect the sales that follow.

Draft and live​

Ticketing on a Rift event passes through two phases:

  • Draft — Attendees can't see or buy tickets. You can freely add, edit, remove, or restructure waves, ticket types, and allocations. Nothing is on sale, so nothing needs protecting.
  • Live — The event is publicly on sale. Attendees can see ticket types, reserve, and check out. Editing rules tighten to keep sales records and issued tickets intact.

The publish action is the one-way transition from draft to live.

Publishing is one-way​

Once published, an event stays published for its lifetime. There's no action to take it back to draft. If you want a different configuration, start over with a new event.

This is a deliberate trade-off. A published event carries promises to attendees — held reservations, issued tickets, sales records — and reversing the lifecycle would put those promises at risk. The strict one-way rule keeps the model unambiguous: in draft, you own the workspace; once live, the platform takes responsibility for the consistency of every sale.

What changes after publish​

Three rules become true at the moment of publish and stay true for the lifetime of the event.

Ticket types and waves can no longer be deleted​

Once an attendee can see a ticket type or wave, deletion is refused. This protects your sales records and the tickets that have already been issued from being silently disconnected by an edit.

To retire something after publish, disable it instead.

Disable is how you retire inventory​

Disable stops new sales on a ticket type or wave without affecting the attendees who already bought. It is reversible — re-enable flips it back.

When you disable an allocation or wave:

  • The public sale stops offering it within seconds.
  • Reservations that were already in progress at the moment of disable continue normally. They either complete (becoming sales) or expire on their existing hold.
  • Because of in-flight reservations, your sold count may climb a little after the action settles.
  • Already-issued tickets are never invalidated. Attendees who already bought see no change.

To retire inventory faster than the in-flight window allows, refund the affected tickets.

Capacity reductions require explicit acknowledgment​

You can still lower the capacity of an allocation after publish, but people already checking out may be unable to finish if the reduced capacity is taken before they complete. The dashboard names this before commit and requires you to acknowledge it.

Capacity cannot be lower than tickets already sold. If more tickets sell while you are reviewing the change, Rift re-checks before saving and may ask you to choose a higher capacity.

Use capacity reduction when the final cap was too high and the new cap is still at or above tickets already sold. If your goal is to stop sales as quickly as possible, disable the allocation or wave first. Disable stops new buyers from starting checkout within seconds. After that, lower the capacity only if you still need to correct the final cap.

What stays editable after publish​

Publish locks down deletion and silent reductions. Additive and in-place changes stay open:

  • Add new waves, ticket types, and allocations. Attendees see them as soon as the platform records the addition.
  • Raise the capacity of an existing allocation. New slots go on sale immediately.
  • Reduce capacity (with the acknowledgment described above).
  • Change price, per-order limit, and reservation hold duration.
  • Adjust a wave's start and end time.
  • Disable and re-enable allocations or waves.
  • Refund tickets. Refunded slots become available again.

The dashboard surfaces the rules of each editing surface inline.

When to publish​

Publish when:

  • The set of ticket types, waves, and allocations matches the event you intend to sell.
  • Wave start and end times are correct.
  • Prices and per-order limits are correct.
  • For paid events, Stripe is connected. The dashboard surfaces a banner if not.

Until those are right, leave the event in draft.