TMPTとKasada：必要なTicketmasterタスクはどちら？

3つの製品すべてで、お客様が用意した HTTP(S) プロキシが必要です。

3つとも同じタスク API を使用し、POST /v1/tasks で作成、GET /v1/tasks/:id で取得します。Bearer 認証ヘッダーにワークスペースの API キーを指定して認証し、そのキーはサーバー上で保持してください。

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

url を対応範囲内の目的の対象に設定し、例のプロキシを置き換えてください。requestId は任意です。Kasada リクエストに site、action、recaptchaType、session、独自のブラウザー識別フィールドを追加しないでください。

返されたブラウザー識別情報と、目的の対象に対して成功したプロキシの出口を使用し、返されたヘッダーをまとめて適用してください。ヘッダーを1つだけ取り出して、TMPT Cookie や reCAPTCHA トークンとして扱わないでください。

Kasada のタスク作成はデフォルトで最大 75 秒待機するため、クライアントのタイムアウトには、その待機時間に加えてネットワークのオーバーヘッドも見込んでください。フロー全体については、Kasada ヘッダーの連携を参照してください。

Event には正確なイベント URL を使用してください。Login にはサインインの開始 URL を使用してください。site、recaptchaType、session は送信しないでください。

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

イベント URL とプロキシを、リクエストに合わせた値に置き換えてください。Kasada とは異なり、TMPT のタスク作成はデフォルトで非同期に返ります。タスク ID を使って結果を取得するか、SDK を使って待機処理を任せてください。

返されるトークンは、tmpt Cookie の生の値です。reCAPTCHA トークンではなく、その Cookie として使用し、関連するブラウザー識別情報とプロキシの出口を一貫させてください。Cookie の扱いについては、Ticketmaster TMPT の連携に従ってください。

ワークフローには複数のチェックが含まれる場合があります。リクエストに TMPT Cookie と Kasada ヘッダーの両方が必要な場合、どちらか一方のタスクを解決しても、もう一方の出力は得られません。さらに reCAPTCHA のチェックが表示される場合は、別のトークンが必要です。最初から 3 つすべてを要求せず、失敗したリクエストに実際に何が必要かを特定してください。

追加の解決に料金を支払う前に、送信リクエストを確認してください。TMPT の値は tmpt Cookie として送信されていますか？Kasada ヘッダーはまとめて適用されていますか？reCAPTCHA トークンは送信先が期待する場所に送信されていますか？タスクが ready であることは、解決結果が生成されたことを意味し、Ticketmaster がリクエストを受け入れたことを意味するわけではありません。結果が拒否された場合は、Ticketmaster 403 の診断に進んでください。