Publishing Rules

Publishing is a validation gate and an irreversible transition. These are the rules it enforces and the ones that apply afterwards.

PreconditionsCopy Anchor Link

Publishing runs these checks inside the publish operation. Each is a hard block, not a warning.

1. 1
   Authority. The caller holds events.publish, the Organization is not suspended, and the Event is not suspended, banned, or archived.
2. 2
   Identity. The Event has a name of 1–160 characters, a non-empty EventCategory, and a non-empty Summary. Description is optional.
3. 3
   Time. The timezone resolves as an IANA zone and the end is after the start.
4. 4
   Place. In-person and hybrid Events need a venue name or a structured Venue or Location. Online and hybrid Events need a valid http or https online URL.
5. 5
   At least one active Pass. Each active Pass has a name, a non-empty attendanceModes set within the Event's participation mode, a valid session scope whose selected Sessions belong to the Event, a sale window (when set) that ends by the Event end, and coherent per-order bounds.
6. 6
   Payment readiness for a paid Event. An approved KYC profile and a verified settlement account. An Indian Organization's paid, non-online Event also needs a venue state for the place-of-supply split.

Publishing does not check media content, team bounds, or payment-account currency routing. Those are enforced on ordinary writes or deferred to checkout. There is no organizer-authored refund or cancellation terms document to validate.

Free Events skip step 6. Drafting skips the whole gate: a draft may be saved without a Summary, without venue or online details, and without any Pass.

What publishing freezesCopy Anchor Link

Publishing does not freeze presentation. Styling, artwork, contacts, sponsors, Topics, and descriptive content stay freely editable.

There is no immutable buyer-facing "published revision". Publishing appends a published revision row for the organizer history, and the lifecycle endpoints append further rows. Ordinary content edits mutate the Event in place and create no revision.

Edits that need no revisionCopy Anchor Link

These are ordinary updates on a published Event. They create no revision record and no buyer notification.

• summary, description, FAQs, contacts, and sponsors
• cover and poster artwork
• presentation styling
• Topics
• visibility
• venue name, address, city, state, country, Venue, Location, and online URL
• EventSeries and EventGroup membership
• a Pass's name, description, list price, and approval-required flag

Venue edits accepted here do not go through the relocate workflow. Only participationMode is refused by a published Event update; the dedicated relocate operation also records a revision and public notice, but a direct patch can change the address without either.

Edits that require a material-change workflowCopy Anchor Link

These changes have a dedicated operation that writes a revision and, for the listed kinds, a public notice on the Event.

• Schedule. reschedule replaces the Event dates, every EventSession date, and submitted Pass sale windows in one transaction.
• Postponement. postpone sets the postponed schedule state with optional new dates; omitting them keeps the original dates visible.
• Resume. resume returns a postponed Event to scheduled with new dates.
• Venue and participation mode. relocate changes the venue details and participation mode together.
• Session schedule or room. Updating an EventSession's start, end, or room appends a session_changed revision.
• Cancellation, completion, archive. Each appends its own revision kind.

Event name, timezone, team mode, team bounds, capacity, fulfillment mode, and slug have no workflow endpoint after publication. They are simply refused with a material_change_required problem.

Notification is not per recipient today. A revision with public: true becomes a Notice on the public Event. Only Event cancellation queues a message to affected buyers.

Edits that are commercially constrainedCopy Anchor Link

A confirmed Order is immutable, so a published Event refuses the changes that would alter what a future buyer is offered.

• Pass price, capacity, per-order limits, and session access cannot change after publication. Existing Order totals, tax splits, and fees are unaffected because the fields themselves cannot move.
• A Pass sale window can move only through reschedule. The new window is validated against the new Event dates, and kept windows that would fall outside the new dates reject the whole reschedule.
• A Pass list price can change after publication. It is display-only; the buyer always pays the offer price.
• New form questions create a new form version. A submission stays sealed against its own version, so a later edit cannot rewrite submitted answers.

Where the rules stopCopy Anchor Link

Three boundaries are unfinished rather than decided by description.

Reconciling a changed participation mode against existing Pass attendance modes and confirmed Registrations is a known follow-up. A relocation validates the new venue and mode but does not reject Passes whose attendance modes no longer fit the Event.

Payment routing is checked when a payment intent is created, not at publish. A paid Event can publish while its currency has no enabled merchant account, and the failure surfaces to the buyer at checkout.

Tax treatment of a hybrid Event's online attendees is unresolved until an accounting decision is recorded; today it follows the hybrid place-of-supply rule. Pricing and tax states the current rule.

RelatedCopy Anchor Link

• Publish an Event — the same checklist as a walkthrough
• Event status — publication in context
• Cancellation — the obligations a cancel creates