TMPT oder Kasada: Welche Ticketmaster-Aufgabe benötigen Sie?

Alle drei Produkte erfordern einen vom Kunden bereitgestellten HTTP(S)-Proxy.

Alle drei verwenden dieselbe Aufgaben-API: Erstellen mit POST /v1/tasks und Abrufen mit GET /v1/tasks/:id. Authentifizieren Sie sich mit einem Workspace-API-Schlüssel im Bearer-Authorization-Header und bewahren Sie diesen Schlüssel auf Ihrem Server auf.

{
  "type": "KasadaTask",
  "url": "https://www.ticketmaster.com/discovery/v2/events",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_kasada_001"
}

Setzen Sie url auf das vorgesehene unterstützte Ziel und ersetzen Sie den Beispiel-Proxy. requestId ist optional. Fügen Sie einer Kasada-Anfrage weder site, action, recaptchaType, session noch benutzerdefinierte Felder zur Browseridentität hinzu.

Verwenden Sie die zurückgegebenen Header zusammen mit der zurückgegebenen Browseridentität und dem erfolgreichen Proxy-Ausgang für das vorgesehene Ziel. Extrahieren Sie nicht einen einzelnen Header, um ihn als TMPT-Cookie oder reCAPTCHA-Token zu behandeln.

Die Kasada-Erstellung wartet standardmäßig bis zu 75 Sekunden. Berücksichtige daher diese Wartezeit sowie den Netzwerk-Overhead beim Timeout deines Clients. Den vollständigen Ablauf findest du in der Integration der Kasada-Header.

Verwende für Event die genaue Event-URL. Verwende für Login die Einstiegs-URL zur Anmeldung. Sende weder site noch recaptchaType oder session.

{
  "type": "TicketmasterTmptTask",
  "url": "https://www.ticketmaster.com/event/EXAMPLE",
  "action": "Event",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "tmpt-event-001"
}

Ersetze die Event-URL und den Proxy durch die Werte für deine Anfrage. Anders als bei Kasada erfolgt die TMPT-Erstellung standardmäßig asynchron. Verwende die Task-ID, um das Ergebnis abzurufen, oder nutze das SDK, um diese Wartezeit zu übernehmen.

Das zurückgegebene Token ist der unveränderte Wert des tmpt-Cookies. Verwende es als diesen Cookie, nicht als reCAPTCHA-Token, und behalte die zugehörige Browser-Identität und denselben Proxy-Ausgangspunkt bei. Hinweise zur Cookie-Verarbeitung findest du in der Ticketmaster-TMPT-Integration.

Ein Workflow kann mehrere Prüfungen umfassen. Wenn eine Anfrage sowohl einen TMPT-Cookie als auch Kasada-Header benötigt, liefert das Lösen nur einer der beiden Aufgaben nicht die jeweils andere Ausgabe. Falls zusätzlich eine reCAPTCHA-Prüfung erscheint, ist dafür ein separates Token erforderlich. Fordere nicht standardmäßig alle drei an, sondern ermittle, was die fehlgeschlagene Anfrage tatsächlich benötigt.

Prüfe die ausgehende Anfrage, bevor du für eine weitere Lösung bezahlst. Wird der TMPT-Wert als tmpt-Cookie gesendet? Werden die Kasada-Header gemeinsam angewendet? Wird ein reCAPTCHA-Token dort gesendet, wo das Ziel es erwartet? Eine Aufgabe mit dem Status ready bedeutet, dass eine Lösung generiert wurde, nicht dass Ticketmaster die Anfrage akzeptiert hat. Fahre bei einem abgelehnten Ergebnis mit der Diagnose eines Ticketmaster-403-Fehlers fort.