TMPT 与 Kasada：你需要哪种 Ticketmaster 任务？

三种产品均需要客户自行提供 HTTP(S) 代理。

三种产品均使用相同的任务 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 或自定义浏览器身份字段。

将返回的请求头作为一组一起应用，并针对预期目标使用返回的浏览器身份信息和求解成功时的代理出口。不要提取单个请求头并将其当作 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 值。将其用作该 cookie，而不是 reCAPTCHA 令牌，并保持关联的浏览器身份和代理出口一致。cookie 处理方式请参阅 Ticketmaster TMPT 集成。

一个工作流可能涉及多项检查。如果请求同时需要 TMPT cookie 和 Kasada 请求头，仅求解其中一种任务并不会提供另一种输出。如果还出现 reCAPTCHA 检查，则需要单独的令牌。不要默认请求全部三种求解；先确定失败的请求实际需要什么。

再次付费求解前，先检查发出的请求。TMPT 值是否作为 tmpt cookie 发送？Kasada 请求头是否一起应用？reCAPTCHA 令牌是否发送到了目标预期的位置？任务状态为 ready 表示已生成解答，并不表示 Ticketmaster 接受了请求。如果结果被拒绝，请继续参阅 Ticketmaster 403 诊断。