Fix a TMPT cookie that is not being sent correctly

Start with a task whose status is ready. If the task is failed, stop polling and inspect errorCode and error; there isn't a usable solution to attach.

The outgoing request has no tmpt cookie.

Compare the request's actual hostname and path with the cookie jar entry's domain and path. Check whether a redirect changed the destination.

Try this: Set the cookie with scope matching the intended target request. Inspect redirects before following them; don't broaden the cookie's domain just to make it appear.

The cookie contains JSON, a task ID, or a repeated tmpt= prefix.

Inspect the value assigned to the cookie, not just whether a Cookie header exists.

Try this: For a cookie jar, use tmpt as the name and solution.token as the value. For an explicit Cookie header, pair that name with the raw value once.

The outgoing request contains multiple tmpt values.

Look for an old explicit Cookie header and jar entries with different domains or paths.

Try this: Replace the intended entry and remove obsolete TMPT entries from that session. Don't concatenate the old and new values or append another tmpt pair.

tmpt is present, but other required session cookies disappeared.

Check whether you created a fresh session or replaced the entire Cookie header with only tmpt.

Try this: Retain the other cookies required by the intended session, with one current TMPT value.

These examples continue after the TMPT task example. They expect a ready result and the original request, created with a single proxy. Both reuse that proxy, the target URL, and the returned userAgent and secChUa.

# Continue after the TMPT example. Install requests separately.
from urllib.parse import urlsplit
import requests

solution = result["solution"]
session = requests.Session()
session.headers.update({
    "User-Agent": solution["userAgent"],
    "sec-ch-ua": solution["secChUa"],
})
session.cookies.set("tmpt", solution["token"],
                    domain=urlsplit(request["url"]).hostname, path="/")
response = session.get(
    request["url"],
    proxies={"http": request["proxy"], "https": request["proxy"]},
    timeout=30,
    allow_redirects=False,
)
print("Target HTTP status:", response.status_code)

// Continue after the TMPT example. Install undici separately: npm install undici@7.
import { fetch, ProxyAgent } from 'undici';

const headers = new Headers({
  'user-agent': result.solution.userAgent,
  'sec-ch-ua': result.solution.secChUa,
});
headers.set('cookie', `tmpt=${result.solution.token}`);
// Merge any other cookies your application requires, with one current tmpt value.
const dispatcher = new ProxyAgent(request.proxy);
try {
  const response = await fetch(request.url, {
    dispatcher, headers, redirect: 'manual',
    signal: AbortSignal.timeout(30_000),
  });
  console.log('Target HTTP status:', response.status);
  await response.arrayBuffer();
} finally {
  await dispatcher.close();
}

The Python example sets the cookie for the target hostname with path /. It creates a fresh Session. If your application needs an existing login session, use that session and replace its old TMPT entry instead.

The Node.js example prepares an explicit Cookie header with one TMPT value. Merge any other required cookies from the same session into that header without appending an old TMPT value. Unlike a cookie jar, a manually prepared header doesn't select cookies by domain and path; use it only for the intended destination.

Both examples leave redirects unfollowed so you can inspect the first target response. They print its HTTP status; they don't establish that the target accepted the cookie or completed the intended action.

• Match the task to the request. TicketmasterTmptTask uses the exact target url: Event takes the event URL, while Login takes the sign-in entry URL. A cookie generated for a different context isn't a replacement for correcting those inputs.
• Use the returned userAgent and secChUa together with the successful proxy. Don't solve through one proxy and send the target request through another. If you supplied proxyCandidates, use the successful proxy rather than choosing an arbitrary candidate.
• Don't treat the raw value as a saved browser session. It doesn't preserve a complete cookie record or establish an expiry time. There is no fixed cookie lifetime to infer from solution.token.

If the cookie is being sent correctly but Ticketmaster still returns 403, continue with Ticketmaster rejection checks.