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 쿠키나 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 쿠키 값입니다. reCAPTCHA 토큰이 아닌 해당 쿠키로 사용하고, 연결된 브라우저 식별 정보와 프록시 출구를 일관되게 유지하세요. 쿠키 처리 방법은 Ticketmaster TMPT 통합을 따르세요.

워크플로에는 여러 검사가 포함될 수 있습니다. 요청에 TMPT 쿠키와 Kasada 헤더가 모두 필요한 경우, 어느 한 작업만 해결해서는 다른 쪽 결과를 얻을 수 없습니다. reCAPTCHA 검사도 표시된다면 별도의 토큰이 필요합니다. 기본적으로 세 가지를 모두 요청하지 말고, 실패한 요청에 실제로 무엇이 필요한지 파악하세요.

다시 해결 비용을 지불하기 전에 발신 요청을 점검하세요. TMPT 값이 tmpt 쿠키로 전송되고 있나요? Kasada 헤더가 함께 적용되고 있나요? reCAPTCHA 토큰이 대상에서 요구하는 위치로 전송되고 있나요? ready 작업은 솔루션이 생성되었다는 뜻이지, Ticketmaster가 요청을 수락했다는 뜻은 아닙니다. 결과가 거부되었다면 Ticketmaster 403 진단을 이어서 확인하세요.