SeatGeek Scraper

Scrapes SeatGeek, the US ticket marketplace: upcoming events with the source's own ticket price statistics (lowest, highest, average and median price, plus listing and ticket counts), venues, and performers (teams, artists, leagues). Search by keyword, category, performer, venue or date range, or paste SeatGeek links.

Quick start

1. Pick Search mode, type a keyword (for example coldplay) and run. You get the matching upcoming events with their price ranges.
2. Or pick URL mode and paste SeatGeek links: event pages (they end in the event id), performer pages (they end in -tickets) or venue pages (they start with /venues/). Event links return one record; performer and venue links return every upcoming event there.

Input summary

Field	Type	Default	Meaning
mode	select	search	Keyword search or paste links.
query	string	coldplay	Search mode: the keyword to look up.
searchType	select	events	Search mode: events, performers or venues.
taxonomy	select	empty	Events search only: narrow to concert, sports, theater, family or comedy.
performerIds	string list	empty	Events search only: numeric performer ids; returns events featuring any of them.
venueId	string	empty	Events search only: numeric venue id; returns events at that venue.
dateFrom / dateTo	string	empty	Events search only: date bounds in YYYY-MM-DD form.
sort	select	empty	Events search only: date, popularity or ticket price ordering.
urls	string list	one example link	URL mode: the SeatGeek pages to read.
maxItems	integer	20	Stop after this many records; 0 means no limit.
maxPages	integer	0	Page cap per scope; 0 (the default) walks until results run out.
proxyConfiguration	proxy	Apify proxy	The default works on every plan.

The Events-only filters (taxonomy, performerIds, venueId, dateFrom, dateTo, sort) sit in the Search mode input section and are applied when the listing URL is built, so they only take effect with Search type: Events. They are ignored by the Performers and Venues directory searches, which is exactly what each field's description says.

Output

Every dataset row carries a kind field:

• kind: "event": one dated occurrence with title, startDateTimeUtc, venue block (venueName, venueCity, coordinates, capacity, timezone), performers (with the headliner), taxonomies, and the source's own price statistics: lowestPrice, highestPrice, averagePrice, medianPrice, goodDealLowestPrice, listingCount, ticketCount.
• kind: "performer": a directory entry with name, performerType, numUpcomingEvents, image and profile link.
• kind: "venue": a directory entry with name, city, state, capacity, coordinates and upcoming-event counts.

Sample rows (illustrative placeholders, not from a live listing):

{
  "kind": "event",
  "recordId": "event:99990001",
  "title": "The Marble Foxes at Riverside Amphitheater",
  "eventType": "concert",
  "startDateTimeUtc": "2027-03-14T23:30:00",
  "venueName": "Riverside Amphitheater",
  "venueCity": "Harborview",
  "lowestPrice": 45.0,
  "highestPrice": 210.0,
  "averagePrice": 88.0,
  "listingCount": 132
}

{
  "kind": "venue",
  "recordId": "venue:99990002",
  "name": "Grand Plaza Arena",
  "city": "Midtown",
  "capacity": 19500,
  "numUpcomingEvents": 42
}

What is covered, and what is not

• No reviews or social surface exists on this source: the marketplace does not publish user reviews for events or venues through the data interface this actor reads, so none are returned. Nothing is invented.
• Per-ticket listings are not covered: the individual ticket offers behind each event require an authenticated account on the source. The actor returns each event's aggregated price statistics instead, which the open data interface publishes for every event.
• Event links must be public SeatGeek pages; password-protected or region-blocked pages cannot be read.

Resume and recurring updates

Two related but different features live in the same input section:

• Resume (resumeFromRunId): paste a previous run ID or dataset ID and the actor skips records already collected there. Use it to continue one large pull that was interrupted.
• Incremental mode (incrementalMode): for scheduled monitoring. The first run returns everything as NEW. Later runs return only NEW, UPDATED and REAPPEARED rows, each stamped with changeType, changedFields, firstSeenAt and lastSeenAt. Rows that vanish are marked EXPIRED (with emitExpired), but only after a run that scanned the whole search without caps or errors.

Note on change detection: ticket prices and listing counts move hourly, so they are deliberately excluded from the change fingerprint. A price move alone does not produce an UPDATED row; a new date, a reschedule, a new venue or a status change does. The live price values are always in the emitted rows.

Send results into your apps (MCP connectors)

You can optionally pipe results into apps you already use via Model Context Protocol (MCP) connectors. Authorize a connector under Apify, Settings, API & Integrations, then select it in the mcpConnectors input field. For Notion, set notionParentPageUrl to the page under which item pages are created; the Notion export writes a page per record with a readable summary. Other connectors get a best-effort write or digest.

Each connector receives a condensed, human-readable summary per record (title plus the key fields flattened to plain text), not the full record. The complete record always stays in the Apify dataset. Use maxNotifyListings to cap how many items each connector receives per run. Leave mcpConnectors empty to skip the export entirely; the dataset output is never changed by the connector surface.

Limits and notes

• The events interface returns at most 100 records per page; the actor walks page by page until maxItems or the natural end of the results.
• A run whose every request was rejected fails loudly with a connection problem message; a search that genuinely matches nothing succeeds quietly with a status message. The two are never confused.
• Results are deduplicated across scopes and pages by record id.