TMPT frente a Kasada: ¿qué tarea de Ticketmaster necesitas?

Los tres productos requieren un proxy HTTP(S) proporcionado por el cliente.

Los tres usan la misma API de tareas: crea con POST /v1/tasks y consulta con GET /v1/tasks/:id. Autentícate con una clave de API del espacio de trabajo en la cabecera de autorización Bearer y conserva esa clave en tu servidor.

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

Establece url con el destino compatible previsto y sustituye el proxy de ejemplo. requestId es opcional. No añadas site, action, recaptchaType, session ni campos de identidad de navegador personalizados a una solicitud de Kasada.

Aplica juntas las cabeceras devueltas, usando la identidad de navegador devuelta y la salida del proxy que funcionó para el destino previsto. No extraigas una sola cabecera para tratarla como una cookie TMPT o un token de reCAPTCHA.

La creación de tareas de Kasada espera hasta 75 segundos de forma predeterminada, así que incluye esa espera y la sobrecarga de red en el tiempo de espera de tu cliente. Consulta la integración de cabeceras de Kasada para ver el flujo completo.

Para Event, usa la URL exacta del evento. Para Login, usa la URL de entrada al inicio de sesión. No envíes site, recaptchaType ni session.

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

Sustituye la URL del evento y el proxy por los valores de tu solicitud. A diferencia de Kasada, la creación de tareas de TMPT devuelve una respuesta de forma asíncrona de manera predeterminada. Usa el ID de la tarea para obtener el resultado o utiliza el SDK para gestionar esa espera.

El token devuelto es el valor sin procesar de la cookie tmpt. Úsalo como esa cookie, no como un token de reCAPTCHA, y mantén la misma identidad de navegador asociada y la misma salida del proxy. Sigue la integración de Ticketmaster TMPT para gestionar las cookies.

Un flujo de trabajo puede incluir varias comprobaciones. Si una solicitud necesita tanto una cookie de TMPT como cabeceras de Kasada, resolver solo una de las tareas no proporciona el otro resultado. Si también presenta una comprobación de reCAPTCHA, esta requiere un token independiente. No solicites los tres de forma predeterminada; identifica qué necesita realmente la solicitud que falla.

Antes de pagar por otra resolución, inspecciona la solicitud saliente. ¿Se envía el valor de TMPT como la cookie tmpt? ¿Se aplican juntas las cabeceras de Kasada? ¿Se envía un token de reCAPTCHA donde lo espera el destino? Una tarea en estado ready significa que se ha generado una solución, no que Ticketmaster haya aceptado la solicitud. Si se rechaza el resultado, continúa con el diagnóstico de un error 403 de Ticketmaster.