Skip to main content

02 — Base Inventory Definition

What it is: The raw tables that hold a faithful copy of vendor seat/price data. Built by polling the vendor API every ~20 minutes. No business logic here — just shaped vendor data, same format regardless of which vendor it came from.

How inventory is built (Ticketmaster)​

Two mandatory calls to the same TM inventory API:

Call 1 — section + price level Returns: how many seats per section, and which price code × ticket type code combinations exist (with prices).

Call 2 — same API + section names + summary=Y Returns seat-level detail per section. Each row:

section, row, first_seat, last_seat, num_seats, seat_increment,
aisle_indicator, class_name, price_code, quality

Field notes:

  • seat_increment — always 1 in practice (seats 1, 2, 3…)
  • aisle_indicator — 0 = none, 1 = left aisle, 2 = right aisle, 3 = both
  • quality — captured but not used yet (added for potential future sorting)
  • This call is not filtering — it's asking for more data; normally all sections are requested

Optional Call 3 — full price code Combines price code (C) + ticket type code (76) into a full code (C76). Fills one column, nothing else depends on it. Costs ~+50% API usage, so it's flag-controlled and can be disabled per team.

Tables​

tbl_seats​

Individual seat rows. Note: price code is NOT on this table — it's in tbl_seat_price_mapping (moved to support TM Host).

tbl_prices​

Pricing rows (price code × ticket type code → price amount).

tbl_seat_price_mapping​

Maps each seat to its price code. This is where you look up what price code a seat has — not on tbl_seats.

Why separated? Price code was split off the seat row to support TM Host's seat/price model.

tbl_sections​

The sections themselves — per-section seat counts / shape from Call 1 (the section/price-summary call).

Rate limits​

TM rate-limits Attend (cap ~120). The main risk is the customer lookup call. Mitigation:

  • Caching aggressively
  • Optional calls (full price code, register-prefill) are flag-controlled so they can be turned off per team

Key rules​

  • All four tables are "raw" — no business logic, same shape regardless of vendor
  • Each vendor has its own service that flattens its API into this shape
  • Price code lives in tbl_seat_price_mapping, not tbl_seats
  • tbl_sections holds the section-level shape; individual seats are in tbl_seats