Skip to main content

Chapter 5 — How a Product Gets Set Up

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

A team signs with Attend and wants to launch, say, a Flex game-pack store. What actually happens? Every Attend product — Flex, Premium, Pass, Flow — follows the same setup pattern. Learn it once and you understand all of them.

The pattern (every product follows it)​

Walking through it:

  1. The team sets up the basics in their ticketing system. The ticketing system owns the real seats, so first the team makes sure their events (games) exist there and marks which seats they want to sell. Teams already do this for their own sales — it's nothing new for them.
  2. Cortex fetches that into Attend's database. Using Cortex (the admin tool), Attend pulls those events and available seats from the vendor and stores a copy in Attend's own database.
  3. Attend adds the "Attend flavor." This is the product-specific logic layered on top — the thing that makes it a 3-game pack, a monthly subscription, or a last-minute offer. "Attend flavor" is just a handy name for "everything Attend adds beyond the raw seats."
  4. The fan-facing store reads from Attend's database. The store the fan sees is now driven by Attend's data — fast, branded, purpose-built.
  5. The fan signs in with their ticketing account (the login from Chapter 3) so Attend knows their account ID.
  6. The fan checks out. Attend calls the vendor's checkout, and the real ticket is created in the vendor's system, attached to that fan.
  7. Attend emails the fan a link to their ticket and records the sale in its own database too.

The one-line version: prerequisites in the vendor → fetch into our database → add the Attend flavor → fan buys → real ticket in the vendor system. The only things that change between products are what data you fetch, what flavor you add, and what the fan sees.

Each store gets its own walled-off space​

A team can run more than one store — maybe a regular Flex store and a separate student store and a Premium suites store. To keep these clean and isolated, each store gets its own separate space in the database — its own PostgreSQL schema, named <client>_<store> (you'll see names like miamidolphins_suites — "the Dolphins' suites store").

Why it matters:

  • Isolation — one client's data never mixes with another's.
  • Variations — the same team can run several stores, each configured differently, without stepping on each other.

But there isn't a server per team. A single flex-v3-backend (and a single cortex-backend) serves every store. How does a request know which team it's for? Each API call carries an X-Team-Schema header; a guard validates it against a whitelist and runs that request against the matching schema. So "which team is this?" is answered per request, by the schema — that's what makes one deployment safely multi-tenant.

You don't need the database details yet — just hold the picture: one store = one isolated, separately configured schema; one shared backend picks the right one per request. (The engineering detail — and why getting it wrong leaks one team's data into another's — is in Write schema-safe backend code.)

Where Cortex fits​

Cortex is the admin app where steps 1–3 happen — picking events, setting prices and discounts, building the inventory. Teams and Attend's ops staff use it; fans never see it. Everything a fan eventually sees was set up in Cortex first.

Example — launching a Warriors 3-game pack: the Warriors confirm their games and sellable seats in Ticketmaster → Attend fetches them via Cortex → Attend configures a "3-game pack, 10% off" on top → the Warriors' Flex store goes live → a fan signs in, buys the pack, and gets three real Ticketmaster tickets, with the sale recorded on Attend's side too.

Recap​

  • Every product follows one pattern: vendor prerequisites → fetch into Attend's DB → add the "Attend flavor" → fan buys → real ticket in the vendor system → email + record.
  • The differences between products are just what you fetch, what flavor you add, and what the fan sees.
  • Each store gets its own isolated space, so a client can run several, cleanly separated.
  • Cortex is the admin tool where all the setup happens.

That's the business half of Attend. From here we go one level deeper — into how ticketing actually works under the hood, which is where the real engineering lives.

Next → Chapter 6 — Ticketing Fundamentals: Section, Row & Seat