Solicita y utiliza una cookie TMPT con cURL

• Para Event, establece url en la URL exacta del evento.
• Para Login, establece url en la URL de entrada al inicio de sesión.
• Proporciona un único proxy para este script. Lo vuelve a utilizar al enviar la cookie al destino.
• No incluyas site, recaptchaType ni session en la tarea TMPT.

El ejemplo usa Login y una URL de la página de inicio de Ticketmaster como marcador de posición. Sustituye la URL de la tarea y el destino final de cURL por las URL reales de tu flujo compatible. Si solicitas una cookie de evento, cambia también la acción a Event.

Ejecuta el script en el servidor con Bash, cURL 7.76 o posterior, jq y openssl. Establece SOLVETHREE_API_KEY en la clave de API de tu espacio de trabajo y SOLVETHREE_PROXY en la URL de tu proxy. Mantén el trazado del shell desactivado: puede exponer la clave, las credenciales del proxy y la cookie.

#!/usr/bin/env bash
set -euo pipefail
: "${SOLVETHREE_API_KEY:?Set the API key}" "${SOLVETHREE_PROXY:?Set the proxy}"
# Requires bash, curl, jq and openssl. Do not enable shell tracing.
work=$(mktemp -d)
chmod 700 "$work"
trap 'rm -rf "$work"' EXIT
request_id=$(openssl rand -hex 16)
printf 'Recovery requestId=%s\n' "$request_id"
printf 'Authorization: Bearer %s\n' "$SOLVETHREE_API_KEY" > "$work/auth"
jq -n --arg proxy "$SOLVETHREE_PROXY" --arg id "$request_id" '{"type":"TicketmasterTmptTask","url":"https://www.ticketmaster.com/","action":"Login","proxy":$proxy,"requestId":$id}' > "$work/input.json"
api='https://api.solvethree.com/v1'
curl --fail-with-body --silent --show-error --max-time 30 \
  --header @"$work/auth" --header 'Content-Type: application/json' \
  --data-binary @"$work/input.json" --output "$work/result.json" "$api/tasks?waitMs=0"
task_id=$(jq -er '.id' "$work/result.json")
encoded_id=$(jq -nr --arg id "$task_id" '$id|@uri')
printf 'Recovery taskId=%s\n' "$task_id"
deadline=$((SECONDS + 180))
while [[ $(jq -r '.status' "$work/result.json") =~ ^(pending|solving)$ ]]; do
  remaining=$((deadline - SECONDS))
  (( remaining > 0 )) || { echo 'Local deadline reached; resume the saved task ID' >&2; exit 1; }
  timeout=$((remaining < 25 ? remaining : 25))
  curl --fail-with-body --silent --show-error --max-time "$timeout" \
    --header @"$work/auth" --output "$work/result.json" "$api/tasks/$encoded_id?waitMs=15000"
  [[ $(jq -r '.status' "$work/result.json") =~ ^(pending|solving)$ ]] && sleep 1 || true
done
[[ $(jq -r '.status' "$work/result.json") == ready ]] || { echo 'Solver task failed' >&2; exit 1; }
user_agent=$(jq -er '.solution.userAgent' "$work/result.json")
client_hints=$(jq -er '.solution.secChUa' "$work/result.json")
cookie=$(jq -er '.solution.token' "$work/result.json")
curl --silent --show-error --max-time 30 --proxy "$SOLVETHREE_PROXY" \
  --cookie "tmpt=$cookie" --user-agent "$user_agent" \
  --header "sec-ch-ua: $client_hints" --output "$work/target-response" \
  --write-out 'Target HTTP %{http_code}\n' 'https://www.ticketmaster.com/'
# Inspect the application's response before treating the operation as successful.
# Replace the example target path with the actual supported workflow URL.

El script se autentica con una clave Bearer, crea una tarea con POST /v1/tasks y después consulta únicamente el ID devuelto con GET /v1/tasks/:id. Tanto pending como solving indican que se debe seguir consultando; solo ready proporciona una solución utilizable.

La creación tiene un tiempo de espera de 30 segundos por solicitud. El bucle de consulta comprueba un plazo local de 180 segundos antes de cada consulta y limita cada solicitud de consulta a un máximo de 25 segundos. Alcanzar ese plazo detiene este script; no demuestra que la tarea remota haya fallado.

Para la solicitud al destino, la opción --cookie de cURL construye la cabecera Cookie a partir del token sin procesar. El script también aplica solution.userAgent, solution.secChUa y el proxy original. No habilita reintentos automáticos ni el seguimiento de redirecciones.

La creación de la tarea agota el tiempo de espera antes de que se imprima un ID de tarea.

Que se agote el tiempo de espera de conexión no demuestra que la API no haya creado la tarea.

Prueba esto: Conserva el requestId impreso y los datos originales de la tarea. Vuelve a enviar esos mismos datos con ese requestId para recuperar la tarea existente en lugar de crear una nueva tarea lógica. Cambiar los datos al reutilizar el ID genera un conflicto.

Una llamada a la API devuelve una respuesta HTTP que no indica éxito.

Este es un error de la capa HTTP, no un estado de tarea. La opción --fail-with-body del script hace que la llamada falle y guarda el cuerpo de la respuesta.

Prueba esto: Inspecciona la respuesta guardada de la API antes de eliminar los archivos temporales. Corrige el problema indicado en lugar de interpretar la respuesta como una tarea correcta o repetir a ciegas los mismos datos de entrada.

El script informa de que la tarea de resolución ha fallado.

El script imprime un mensaje de fallo genérico; la tarea fallida contiene errorCode y error.

Prueba esto: Recupera el ID de tarea impreso e inspecciona esos campos. Deja de consultar una tarea fallida. Las resoluciones fallidas se reembolsan.

Se agota el plazo local de consulta.

La tarea puede seguir pendiente o en resolución.

Prueba esto: Reanuda las consultas con el ID de tarea impreso. No crees otra tarea solo porque el script local haya dejado de esperar.

La tarea está lista, pero el destino rechaza la solicitud.

Inspecciona la cookie saliente, el agente de usuario, las pistas de cliente, el proxy y la URL de destino, no solo el estado de la resolución.

Prueba esto: Confirma que la cookie tmpt contiene solution.token, sin prefijo Set-Cookie ni atributos. Usa la identidad devuelta y el proxy original, y comprueba que la URL de destino coincide con el flujo previsto.