Event Data Schema & Configuration

This page walks through the event object that sits behind every listing on BrightStar — the same structure whether you're a retreat host filling out the dashboard form or a developer wiring up an API integration for a festival series. You'll reach for it any time you're troubleshooting why a kirtan night won't move out of draft, why a retreat's dates look wrong somewhere downstream, or why a custom URL for a sound healing weekend got rejected. The schema below is the actual shape of the data: the fields the system requires, the fields it fills in for you, and the rules that decide whether a change goes through or gets pushed back to draft.

Four fields are required on every event, full stop: title (1 to 100 characters), start_date as an ISO 8601 datetime, timezone as an IANA timezone string, and organizer_id, which ties the event to your account. Beyond that, a few requirements depend on what kind of gathering you're running. A multi-day retreat needs an end_date. An in-person kirtan or ceremony needs a venue address. A breathwork session held online needs an online_url. These conditional rules exist because the same event object has to describe wildly different situations — a single evening at a downtown studio, a three-day retreat in Sedona, a livestreamed session with no physical address at all — and the schema only asks for what that particular situation actually needs. Some fields you never fill in yourself: the id, the slug (if you don't set one), and the created_at and updated_at timestamps are generated by the system.

Each field carries its own limits, worth knowing before you hit save. A title has to be between 1 and 100 characters; letters, numbers, spaces, and basic punctuation are allowed, while HTML tags and emoji are stripped out when the title becomes part of a URL slug. A description can run up to 50,000 characters and accepts sanitized HTML and markdown, so you can format a retreat itinerary or a ceremony's lineage with headings and lists — but scripts, iframes, and externally hosted images are blocked, which keeps a careless or compromised embed from affecting other people's event pages. A start_date has to sit at least one hour in the future for a new event, and an end_date always has to fall after the start_date — small checks that catch the kind of typo that would otherwise open a doorway before anyone's ready or close it before anyone's arrived. Event images accept JPG, PNG, or WebP, are recommended at 1920x1080 pixels, capped at 10MB, and are optimized automatically once they hit BrightStar's CDN, so a bigger source file than the recommendation still ends up loading quickly on someone's phone at the door.

Cancelling isn't the same as deleting, and it isn't reversible into a republish. When you cancel a published BrightStar event, new sales stop right away, but tickets that already sold stay valid — the people holding them still have a valid ticket unless you choose to trigger an automatic refund. Because a cancelled event can't move back to published, cancelling is a decision you make once you're reasonably sure the gathering isn't happening in its current form; if plans change and it does go ahead, the path is a new event, not resurrecting the old one.