Chapter 13 — Events & Venues

Attend onboarding guide · ~6 min read · ↑ Back to contents

Programs and packs are built out of events, and events happen at venues. Both are simple entities — but each has a couple of sharp edges worth knowing before you touch the data.

The event entity

An event is one game (or show). Attend fetches it from the vendor, and from then on most of its fields are editable — name, date, time, opponent — so a team can tidy up labels. One field is not:

• event_code comes from the vendor and is never editable. It's the key Attend uses to talk to the ticketing system about this event, so it must always match the vendor exactly. Treat it as read-only forever.

TBD vs TBA — they're not the same

Sports schedules are messy, so events carry a status for unconfirmed dates, and the two look-alike acronyms mean different things:

Status	Meaning
TBD	The date hasn't been decided yet.
TBA	The date is decided, just not publicly announced yet.

When a date is TBD, sorting would break — so an event also has an estimated_date used only for sorting. It's never shown to the fan; it just keeps a TBD game in roughly the right place in the list.

Two more knobs

• Per-event min/max — an anti-broker guardrail (cap how many of one game a single buyer can take). Rarely used.
• Event categories — a UI-only grouping/filter. For a Live Nation client, categories might be "Rock" and "Pop"; they don't change pricing or access, just how events are grouped on screen.

The reference event code applies globally

This one confuses almost everyone the first time. When a team configures suites or inventory, they hand Attend one event code to fetch the available seats from the ticketing system. It's natural to think that config belongs to that event — but it doesn't:

Wherever you see an event code used to fetch inventory, it's just a reference — it applies globally, not to that one event.

The reason is mechanical: the ticketing system only lets you fetch one event at a time. So teams pick any event as a proxy, pull the seat map once, and that configuration then applies to all events in the program. The event code there is a handle for fetching, not a scope.

Venues

You met the venue in Chapter 6: a venue has a manifest (its seat layout), and each event links to a manifest. Here we add the seat map — the picture of those seats that a fan actually browses. The map is the visual rendering of the manifest; it's not a separate layout.

• Today a venue usually shows one map.
• The plan is to support multiple maps side by side — e.g. a 3D map next to a static one — but that's not in Cortex yet.
• Premium's 3D maps are built by 3D Digital Venue, the same maps vendor introduced in Chapter 6.

A note on add-ons (full deep-dive later)

Programs can also sell add-ons, at three levels:

• Event level — e.g. parking for one specific game.
• Order level — e.g. merchandise bundled with any purchase.
• Suite level — e.g. food & beverage included with a suite.

They're built from the same primitives you already know (price code, ticket type code, class names) and sold via the dummy-event trick from Chapter 9. Add-ons are a big entity in their own right and get a full session later — for now, just know the three levels exist.

Recap

• event_code is vendor-owned and never editable; everything else on an event can be tidied up.
• TBD = date undecided; TBA = decided but unannounced. estimated_date sorts TBD events and is never shown to fans.
• A fetch event code is a global reference, not per-event — the vendor only lets you fetch one event at a time.
• A venue has a manifest (the seat layout); its seat map is the visual rendering of that manifest (one today, multiple planned). Premium's 3D maps come from 3D Digital Venue.
• Add-ons come at event / order / suite levels — deep-dive later.

---

Next → Chapter 14 — Who Gets In: Gating & Account Groups