Ticketmaster returns 403 after a solve: what to check

api.solvethree.com returned HTTP 403.

The documented inactive-profile 403 applies to reCAPTCHA. Kasada and TMPT use separate task types and do not require a reCAPTCHA site profile. Check which task body you sent and read the API response.

Try this: For reCAPTCHA, activate the correct site profile. Kasada and TMPT use their own type and URL and do not require that profile. Contact support if a correctly shaped task still returns 403.

The API request succeeded, but the task is failed.

Read the task's errorCode and error. An HTTP response status and a terminal task failure are separate errors.

Try this: Stop polling that task and address its reported error before retrying. Failed solves are refunded; don't keep submitting unchanged invalid inputs.

The task is ready, but Ticketmaster returned HTTP 403.

Inspect the outgoing Ticketmaster request. A ready task contains a usable solution, but doesn't establish downstream acceptance.

Try this: Check the URL, solution placement, proxy and browser identity below. A target 403 alone doesn't identify which protection rejected the request.

Compare the task input with the request Ticketmaster rejected. A solution for another URL isn't a substitute, and TMPT cookies and Kasada headers aren't interchangeable.

• For TicketmasterTmptTask with action Event, use the exact event URL.
• For TicketmasterTmptTask with action Login, use the sign-in entry URL.
• For KasadaTask, use the intended HTTPS target URL on www.ticketmaster.com. That's the currently supported hostname for standalone Kasada.

If the integration expects a cookie but created a Kasada task—or expects headers but created a TMPT task—correct the task type rather than trying to convert its output. See TMPT versus Kasada if you're unsure which output the request needs.

Inspect the outgoing request, not just the variables passed to your HTTP client. An old cookie or a client default can leave the request different from what your application intended.

TMPT is ready, but the request is rejected.

Check that the intended Ticketmaster request carries the returned value as the tmpt cookie, rather than an old cookie or a token in another field.

Try this: Send the raw returned value as the tmpt cookie. It isn't a reCAPTCHA token or a Kasada headers object. See the TMPT integration guide.

Kasada is ready, but the request is rejected.

Compare the outgoing headers with the complete returned headers object. Look for omitted or overwritten values.

Try this: Apply the returned headers together to the intended target request. Don't select only one header. See the Kasada headers guide.

The application submits through a different proxy.

Compare the application's egress with the proxy that successfully produced the solution. If you supplied proxyCandidates, don't assume the first candidate succeeded.

Try this: Use the successful proxy for the target request.

The client uses its own browser identity.

Check whether client defaults overwrite the returned userAgent or secChUa.

Try this: Use the returned browser identity with the successful proxy and intended target URL. Don't combine it with an unrelated user agent or client hints.

If these checks don't explain the rejection, contact [email protected] with:

• The task ID and requestId, if supplied.
• The product or task type and the timestamp of the failure.
• Which host returned the error, its HTTP status, and any task errorCode and error.
• The target hostname and action: Event or Login for TMPT.
• A sanitized description of the response and which URL, cookie or headers, proxy, and browser-identity checks you completed.

Remove API keys, proxy passwords, tokens, cookies and customer data before sending the report.