Request and use a TMPT cookie with cURL

• For Event, set url to the exact event URL.
• For Login, set url to the sign-in entry URL.
• Supply a single proxy for this script. It uses that proxy again when sending the cookie to the target.
• Do not include site, recaptchaType, or session in the TMPT task.

The example uses Login and a placeholder Ticketmaster homepage URL. Replace the task URL and final cURL target with the actual URLs for your supported workflow. If you're requesting an event cookie, change the action to Event as well.

Run the script server-side with Bash, cURL 7.76 or later, jq, and openssl. Set SOLVETHREE_API_KEY to your workspace API key and SOLVETHREE_PROXY to your proxy URL. Keep shell tracing off: it can expose the key, proxy credentials and 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.

The script authenticates with a Bearer key, creates one task with POST /v1/tasks, then polls only its returned ID with GET /v1/tasks/:id. Both pending and solving mean polling should continue; only ready supplies a usable solution.

Creation has a 30-second request timeout. The polling loop checks a 180-second local deadline before each poll and limits individual polling requests to at most 25 seconds. Reaching that deadline stops this script; it doesn't establish that the remote task failed.

For the target request, cURL's --cookie option builds the Cookie header from the raw token. The script also applies solution.userAgent, solution.secChUa, and the original proxy. It enables neither automatic retries nor redirect following.

Task creation times out before a task ID is printed.

A connection timeout doesn't prove that the API failed to create the task.

Try this: Keep the printed requestId and original task inputs. Resubmit those same inputs with that requestId to recover the existing task instead of creating a new logical task. Changing inputs while reusing the ID conflicts.

An API call returns a non-success HTTP response.

This is an HTTP-layer error, not a task status. The script's --fail-with-body option makes the call fail while saving the response body.

Try this: Inspect the saved API response before temporary-file cleanup. Correct the reported problem rather than parsing the response as a successful task or blindly repeating unchanged inputs.

The script reports that the solver task failed.

The script prints a generic failure message; the failed task contains errorCode and error.

Try this: Retrieve the printed task ID and inspect those fields. Stop polling a failed task. Failed solves are refunded.

The local polling deadline expires.

The task may still be pending or solving.

Try this: Resume retrieval using the printed task ID. Don't create another task merely because the local script stopped waiting.

The task is ready, but the target rejects the request.

Inspect the outgoing cookie, user agent, client hints, proxy and target URL—not just the solver status.

Try this: Confirm that the tmpt cookie contains solution.token, without a Set-Cookie prefix or attributes. Use the returned identity and original proxy, and check that the target URL matches the intended workflow.