Ticketmaster scrapen 2026 (API & Python)

Ticketmaster ist eine der wenigen Plattformen in dieser Serie mit einer echten, kostenlosen Self-Service-API — die Discovery API deckt Events, Venues und Attractions ab, mit einem großzügig genug bemessenen kostenlosen Kontingent für ein einzelnes Lookup-Tool. Die ehrliche Frage lautet also nicht „Hat Ticketmaster eine API?", sondern „Wann ergibt eine strukturierte Multi-Plattform-API mehr Sinn, als Ticketmasters eigenen Key und eigenes Kontingent im Alleingang zu betreiben?". Dieser Guide behandelt die Discovery API, No-Code-Optionen und eine strukturierte API — mit der rechtlichen Realität zu jeder Option gleich vorneweg.

Warum Ticketmaster scrapen?

Ticketmasters Event-, Venue- und Artist-Daten bilden das Fundament der meisten Live-Entertainment-Tools und treiben an:

• Event Discovery und Monitoring — neue Event-Listings, Onsale-Zeiten und Presale-Fenster für einen Artist, ein Team oder eine Venue im Blick behalten.
• Tour- und Artist-Tracking — den kompletten Event-Zeitplan einer Attraction (Artist oder Team) über mehrere Städte hinweg verfolgen.
• Venue-Recherche — kanonische Venue-Adresse, Geo-Koordinaten und kapazitätsnahe Metadaten an ein Listings- oder Local-Events-Produkt anhängen.
• Browsing nach Stadt und Kategorie — eine „Was läuft"-Übersicht nach Stadt oder Discovery-Kategorie (Musik, Sport, Arts & Theatre) bauen.
• Plattformübergreifende Event-Recherche — Ticketmaster-Listings mit ESPN-Spielplänen für Sport oder Suchnachfrage für Artists und Tours kombinieren, statt dich auf eine einzige Quelle zu verlassen.

Ist es legal, Ticketmaster zu scrapen?

Option 1: Ticketmasters eigene Discovery API (und ihre echten Grenzen)

Ticketmasters Discovery API ist echt und funktioniert. Registriere ein kostenloses Konto, hol dir einen API-Key und ruf sie direkt auf — kein Scraping nötig:

curl "https://app.ticketmaster.com/discovery/v2/events.json?keyword=ariana%20grande&apikey=YOUR_TICKETMASTER_API_KEY"

Das liefert Ticketmasters eigene Event-Suchergebnisse zurück — laut Discovery-API-Docs inklusive eines priceRanges-Arrays (Currency, Min, Max) und eines sales-Objekts mit öffentlichen Onsale-/Presale-Daten und Status (onsale, offsale, canceled, postponed, rescheduled) für Events, die über Ticketmasters eigenes primäres Inventar verkauft werden. Preise und Sale-Status sind also nicht von der kostenlosen API abgeschottet — das lohnt sich, selbst zu verifizieren statt anzunehmen, denn hier liegt man leicht falsch.

Wo das für eine größere Pipeline anfängt, weniger relevant zu sein:

• Das Standardkontingent ist real, aber begrenzt. Laut Developer Portal liegt der Standard bei 5.000 API-Calls/Tag mit bis zu 5 Requests/Sekunde — großzügig für einen einzelnen Artist-Tracker, eng, wenn du viele Artists, Städte oder Venues nach Zeitplan pollst. Höhere Kontingente gibt's auf Anfrage im Einzelfall.
• Ein eigenes Konto, ein eigener Key und ein eigenes Kontingent pro Plattform. Wenn dein Produkt zusätzlich ESPN-Spielpläne oder andere Event-/Venue-Quellen zieht, ist die Discovery API ein weiteres Auth-Modell, ein weiteres Tageskontingent und eine weitere Response-Form, die du neben den anderen verwalten musst.
• Das ist Ticketmasters eigene Inventar-Sicht. Die Pricing- und Sale-Status-Felder der Discovery API spiegeln Ticketmasters eigenen Primärverkauf wider, nicht Secondary-/Resale-Marktplätze oder den vollständigen internen Status jedes Promoters — das solltest du gegen das prüfen, was dein Use Case tatsächlich braucht.

Option 2: No-Code-Tools

Für Ticketmaster-nahe Workflows gibt es Marketplace-Scraper-Actors und No-Code-Connectors — die meisten wrappen entweder die Discovery API oder versuchen sich direkt an der Website, was die Terms of Use oben ausdrücklich einschränken. Für einen einmaligen Abzug oder einen Spreadsheet-Export sind sie in Ordnung, aber für eine geplante Pipeline fügen sie eine zusätzliche Indirektionsebene über eine API, die du sonst direkt aufrufen könntest, hinzu — und das Multi-Plattform-Schema-Problem lösen sie auch nicht.

Option 3: Eine strukturierte Ticketmaster-API (via Crawlora)

Wenn du Ticketmaster neben anderen Plattformen in einer einheitlichen, normalisierten Form willst — derselbe Auth-Header, konsistentes JSON, kein separates Daily-Quota-Tracking, das du bauen musst —, liefert dir das eine Ticketmaster scraping API. Suche Events nach Keyword:

curl "https://api.crawlora.net/api/v1/ticketmaster/search-events?q=ariana+grande" \
  -H "x-api-key: $CRAWLORA_API_KEY"

{
  "code": 200,
  "msg": "OK",
  "data": {
    "query": "ariana grande",
    "page": 0,
    "sort": "relevance",
    "total": 28,
    "count": 1,
    "events": [
      { "id": "04006319DDEA2CD5", "title": "Ariana Grande - The Eternal Sunshine Tour", "venue": { "id": "32882", "name": "United Center" } }
    ]
  }
}

Löse dann die Venue-id auf und hol dir das Venue-Detail in Python:

import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/ticketmaster"

hits = requests.get(f"{base}/search-events", headers=h, params={"q": "ariana grande"}).json()["data"]["events"]
venue_id = hits[0]["venue"]["id"]

event = requests.get(f"{base}/event", headers=h, params={"id": hits[0]["id"]}).json()["data"]["event"]
venue = requests.get(f"{base}/venue", headers=h, params={"id": venue_id}).json()["data"]["venue"]

Venue-Detail ist normalisiertes JSON (echte Felder — sieh dir die docs an):

{
  "code": 200,
  "msg": "OK",
  "data": {
    "venue": {
      "id": "32882",
      "name": "United Center",
      "address": "1901 W Madison",
      "city": "Chicago",
      "state": "IL",
      "postal_code": "60612",
      "country": "US",
      "latitude": 41.881244,
      "longitude": -87.674274,
      "time_zone": "America/Chicago",
      "info": [{ "name": "Box Office", "text": "Open event days" }]
    }
  }
}

Event-Detail liefert Venue, Attractions, Classification (Segment/Genre/Sub-Genre) und Availability-Signale — sold_out, limited_availability, ticketing_status, onsale_time und presales (Name, Start-/Endzeit) — als normalisierte Booleans und Strings, ein Call pro id. /ticketmaster/attraction und /ticketmaster/attraction-events machen dasselbe für Artists und Teams; /ticketmaster/discover-cities und /ticketmaster/discover-city-events browsen nach Stadt; /ticketmaster/discover-categories und /ticketmaster/discover-category-events browsen nach Segment (Musik, Sport, Arts & Theatre); /ticketmaster/suggest liefert schnelle Autocomplete-Vorschläge. Speichere eine Zeile pro Event (oder Venue oder Attraction) und lass es nach Zeitplan erneut laufen.

Was du sammeln kannst

Öffentliche Ticketmaster-Katalogdaten: Event-Suche und -Detail (Title, Startzeit, Zeitzone, Venue, Attractions, Classification, Currency, sold_out-/limited_availability-/ticketing_status-Flags, Onsale- und Presale-Timing, Seatmap-URL); Attraction-Detail und die vollständige Event-Liste einer Attraction (Artists, Teams, Classification); Venue-Detail (Adresse, Stadt, Bundesland, Postleitzahl, Land, Breiten-/Längengrad, Zeitzone, Besucherinfo) und die vollständige Event-Liste einer Venue; Städte-Browsing (paginierte Städteliste nach Land) und Events nach Stadt; Discovery-Kategorien (Segment-/Genre-Hierarchie, paginiert nach Section) und Events nach Kategorie; sowie Autocomplete-Vorschläge (Query, Type — Artist, Venue, Event).

Grenzen und typische Herausforderungen

• Wisse, durch welche Tür du gehst. Ticketmasters eigene Discovery API ist kostenlos und für direkten API-Zugriff legitim; das Scrapen der Website ticketmaster.com selbst verstößt in jedem Fall ausdrücklich gegen die Terms of Use.
• Keine numerischen Preisspannen in den hiesigen normalisierten Event-Daten. Anders als Ticketmasters eigene Discovery API, die priceRanges (Min/Max) zurückgibt, zeigt das Event-Detail dieser API Availability-Signale (sold_out, ticketing_status, onsale_time) statt Ticketpreise — sieh in den Docs nach, falls numerisches Pricing ein Hard Requirement ist.
• Pagination ist begrenzt. search-events-Pages sind nullbasiert, 0–49, eine einzelne Query deckelt also bei rund 50 Ergebnisseiten; grenz nach Keyword, Stadt oder Kategorie ein, statt zu versuchen, alles durchzublättern.
• Fan-out pro Datensatz. Ein vollständiger Event-, Attraction- oder Venue-Datensatz ist ein Call pro id; einen Katalog aufzubauen bedeutet, ids aus Search-, City- oder Category-Endpoints zu durchlaufen.
• Nur öffentliche Daten. Das hier sammelt, was öffentlich gelistet ist — niemals ein Weg, um Ticketmasters Website-Restriktionen oder die Lizenzbedingungen der eigenen API für High-Volume- oder Resale-Use-Cases zu umgehen.

Wo das eingesetzt wird

• Tour- und Artist-Tracking — den Event-Zeitplan eines Artists oder Teams über Venues und Städte hinweg überwachen.
• Lokale „Was läuft"-Übersichten — Event-Discovery nach Stadt oder Kategorie bauen.
• Venue-Recherche — kanonische Adress- und Geo-Daten an ein Local-Events- oder Listings-Produkt anhängen.
• Plattformübergreifende Event-Recherche — Ticketmaster-Listings mit ESPN-Spielplänen für Sport oder Google Trends-Suchnachfrage für Artists und Tours kombinieren.

Sources

Leg los mit dem Sammeln

Probier es zuerst kostenlos aus: jage eine beliebige öffentliche URL durch den Free Web Scraper oder prüfe mit dem Anti-Bot Checker, ob eine Seite Bots blockiert — ohne Anmeldung.

Teste die Search-, Event- und Venue-Endpoints im Playground, sieh dir das Schema in den API docs an und wirf einen Blick aufs pricing. Ticketmaster sagt dir, was im Verkauf ist und wo; ESPN deckt die Live-Sport-Spielpläne ab, die direkt neben den getickerten Spielen liegen, how to scrape MLB deckt speziell die Spielplan-Seite genau derselben Baseball-Spiele ab, und Google Trends stellt die Suchnachfrage nach einem Artist oder einer Tour dem tatsächlichen Ticket-Search-Interesse gegenüber. Siehe auch how to choose a web scraping API und is web scraping legal.