La tarea está lista. ¿Por qué se rechaza el token de reCAPTCHA?

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

En este ejemplo, solution.token es el valor que debes enviar donde el destino espere su token de reCAPTCHA. id identifica la tarea de solvethree; no es un token. Tampoco envíes el objeto de solución completo.

Inspecciona la solicitud saliente final, no solo la variable que contiene la respuesta. Comprueba que contiene el token actual y no un valor vacío o un token anterior que haya quedado en el formulario. No incluyas tokens en registros compartidos.

El token enviado es correcto, pero el destino sigue rechazándolo.

Compara el nombre de host del sitio de la tarea con el nombre de host de la solicitud protegida. Comprueba si hay un subdominio o un entorno diferente.

Prueba esto: Solicita el token para el nombre de host previsto y envíalo a ese destino. El sitio de destino debe tener un perfil activo disponible para tu espacio de trabajo.

Se usa un token solicitado para una interacción en otra distinta.

Compara la acción de la tarea con la acción exacta que se espera para esta solicitud protegida.

Prueba esto: Usa la acción asociada a la interacción que vas a enviar.

La integración usa una variante incorrecta de reCAPTCHA.

Revisa recaptchaType en la solicitud de la tarea. Su valor predeterminado es enterprise-v3; la pasarela también acepta v3.

Prueba esto: Especifica explícitamente el producto del destino. Para Enterprise v3, usa enterprise-v3.

Los tokens de respuesta para sitios web tanto de reCAPTCHA clásico como de reCAPTCHA Enterprise caducan a los dos minutos y son de un solo uso. Los tokens clásicos se pueden verificar una vez; los de Enterprise se pueden evaluar una vez. Realiza la resolución poco antes de la solicitud protegida en lugar de mantener una reserva de tokens listos.

• Si el envío se retrasa, comprueba cuánto tiempo pasó entre la resolución y el envío del token.
• Si el token ya se verificó o evaluó, no lo reutilices para otro envío.
• No realices una verificación independiente ni una evaluación de Enterprise solo para probar el token antes de enviarlo al destino. Esa prueba puede consumirlo.

La resolución se completa correctamente, pero el envío usa otra conexión.

Compara el proxy que funcionó para la resolución con el usado para la solicitud protegida. Si proporcionaste proxyCandidates, no des por hecho que funcionó el primer candidato.

Prueba esto: Envía la solicitud a través del proxy que funcionó. Cambiar de IP entre la resolución y el envío puede hacer que la solicitud falle.

El cliente que realiza el envío usa sus propias cabeceras de navegador predeterminadas.

Compara los valores salientes de User-Agent y Sec-CH-UA con solution.userAgent y solution.secChUa.

Prueba esto: Usa la identidad de navegador devuelta junto con el proxy que funcionó. No combines el token con valores de user-agent o client hints ajenos.

Revisa tanto el cuerpo de la respuesta del destino como su estado HTTP. Un 403 por sí solo no identifica qué protección rechazó la solicitud. Busca un error explícito del token o una discrepancia de nombre de host o acción antes de solicitar otro token.

Si hay detalles de verificación disponibles, comprueba el resultado success de reCAPTCHA clásico y la información de contexto o error devuelta. Para Enterprise, revisa la validez del token y los motivos de evaluación pertinentes. No des por hecho que una puntuación por sí sola explica el rechazo: el sitio web decide cómo usar la evaluación.

Si sigues sin poder identificar la causa, contacta con [email protected] e incluye el ID de la tarea y requestId, si se usó, el producto, la marca de tiempo, el nombre de host y la acción del destino, el estado HTTP o el error de la tarea y una descripción de la respuesta sin información sensible. Elimina las claves de API, las contraseñas de proxy, los tokens, las cookies y los datos de clientes.