🎉NUEVOCapSolver para agentes de IA-Integraciones de MCP, herramientas de agente y SDK
Aloísio Vítor
Image Processing Expert
Publicado Oct 26, 2026
Actualizado Oct 26, 2026 · min de lectura
ERROR_TASK_NOT_SUPPORTED significa que el tipo de CAPTCHA enviado es incorrecto o no está soportado por el servicio.task.type que realmente se envía por la red, no solo la etiqueta mostrada en la configuración de un framework.Una integración de CAPTCHA puede fallar antes de que comience el reconocimiento. La API recibe una solicitud, examina su tipo de tarea y rechaza una operación que no soporta. En esa situación, cambiar la clave pública del sitio, esperar más tiempo o aumentar los reintentos puede dejar el problema real sin tocar.
CapSolver documenta ERROR_TASK_NOT_SUPPORTED por separado de los datos de tarea inválidos y del reconocimiento fallido. La ruta útil de solución de problemas consiste en comparar la solicitud que tu aplicación realmente envía con el contrato del servicio y la superficie de integración que estás utilizando.
ERROR_TASK_NOT_SUPPORTED identifica un problema de compatibilidad del tipo de tarea; no establece que la imagen CAPTCHA fuera difícil ni que un token devuelto haya expirado.
La referencia oficial de códigos de error define esta condición como un tipo de CAPTCHA incorrecto o no soportado. Conserva tanto errorCode como errorDescription al revisar el fallo. Un mensaje genérico de la aplicación como “el solucionador falló” pierde la distinción necesaria para elegir la corrección adecuada.
Empieza con tres hechos: qué endpoint recibió la solicitud, qué cadena de tipo exacta recibió y qué familia de CAPTCHA estaba presente en la página. Estos son los elementos mínimos necesarios para comparar la implementación con la documentación.
Un parámetro de API forma parte de un contrato de servicio. Un nombre que parece razonable no es necesariamente un nombre soportado. La capitalización, la ortografía, los sufijos y las variantes específicas de cada familia deben provenir de la referencia oficial y no de un patrón de nombres inferido de otro proveedor.
Inspecciona la solicitud saliente después de que tu SDK, capa de configuración o middleware la hayan transformado.
Una pantalla de configuración puede decir “reCAPTCHA v2”, mientras que el JSON final contiene una cadena diferente. Una variable de entorno puede seguir teniendo un valor retirado. Un wrapper puede mapear un nombre amigable a un identificador de tarea que ya no coincide con el servicio que llama. Lee el valor efectivo en lugar de suponer que la configuración inicial llegó a la API sin cambios.
Para un cliente basado en navegador, el panel Network de Chrome explica cómo inspeccionar una solicitud y una respuesta. Para código del lado del servidor, usa un registro de diagnóstico de alcance reducido sin secretos. Evita registrar claves de API, cookies de sesión, tokens completos o datos de formularios no relacionados.
Registra el método, el host y la ruta de destino, el tipo de tarea, los nombres de los campos y el código y la descripción de la respuesta. Incluye un ID de tarea solo si el servicio realmente devolvió uno. Un fallo en la creación de la tarea puede dejarte sin un identificador válido para hacer polling.
Un JSON sintácticamente válido no demuestra que una tarea esté soportada. La especificación JSON describe un formato de datos; la referencia de la API define el significado permitido de sus campos.
Esa distinción ayuda cuando un validador dice que la solicitud está bien formada pero la API aún la rechaza. Una cadena sintácticamente correcta puede seguir nombrando una operación no soportada. A la inversa, los datos mal formados merecen su propio diagnóstico en lugar de tratarse como el mismo error.
Haz coincidir la familia y la variante actuales del CAPTCHA antes de seleccionar un tipo de tarea de reemplazo.
Usa la visión general de tipos de tarea para localizar la familia correcta y luego abre la referencia detallada de esa familia. Por ejemplo, la referencia de tarea de reCAPTCHA v2 enumera los nombres de tarea v2 aceptados y sus campos. Copia el identificador de la entrada relevante en lugar de construirlo de memoria.
Revisa la página real otra vez si la aplicación cambió recientemente su integración de CAPTCHA. Una configuración histórica puede describir un proveedor o variante anteriores. La apariencia de un widget por sí sola no basta para demostrar que la tarea antigua sigue siendo aplicable.
Revisa también el límite entre una tarea de token y una tarea de reconocimiento. Una puede devolver un token para un flujo de aplicación, mientras que otra responde a una solicitud de reconocimiento de imagen. Tratar esas tareas como intercambiables solo porque ambas involucran CAPTCHA puede producir el contrato de solicitud equivocado.
No experimentes con nombres de tarea aleatorios hasta que uno sea aceptado. Eso oscurece el fallo original y puede dar lugar a una operación distinta de la que tu aplicación necesita.
Canjea tu código de bono de CapSolver
Impulsa tu presupuesto de automatización al instante.
Usa el código de bono CAP26 al recargar tu cuenta de CapSolver para obtener un 5% de bono extra en cada recarga, sin límites.
Canjéalo ahora en tu Panel de CapSolver
Mantén los nombres de cada superficie de integración dentro de la interfaz que los define.
Una solicitud REST envía un objeto de tarea. Un SDK puede exponer métodos y valores de detección normalizados. Un cliente MCP llama a herramientas nombradas con su propio esquema de entrada. Un nombre devuelto por una capa no es automáticamente un task.type válido en otra capa.
Por ejemplo, la referencia del Core SDK explica sus métodos de navegador y de resolución. Al usar ese SDK, sigue sus parámetros documentados. Al construir una solicitud REST directamente, usa la referencia de tareas REST. Al usar MCP, inspecciona el esquema de la herramienta en lugar de colocar el nombre de la herramienta en un campo de tarea REST.
Esto importa durante las migraciones. Reemplazar un paquete o cambiar un host de API puede dejar valores de configuración antiguos en su lugar. Incluso servicios con estructuras de respuesta similares pueden soportar identificadores de tarea y campos opcionales diferentes. Compara explícitamente los contratos de origen y destino.
Una característica no soportada debe seguir no soportada hasta que el proveedor documente una ruta soportada. No sustituyas silenciosamente una familia de desafíos distinta solo para que la solicitud pase la validación.
Valida una solicitud corregida antes de permitir que la misma configuración llegue a todos los workers.
Primero detén la repetición automática de la solicitud incompatible conocida. Luego cambia la discrepancia específica que identificaste y ejecuta una prueba acotada. Revisa el estado y los campos devueltos antes de habilitar de nuevo el flujo de trabajo más amplio.
La guía HTTP sobre reintentos de solicitudes no idempotentes es relevante cuando un fallo de red deja incierto el resultado de una operación. No supongas que una nueva solicitud de creación de tarea es intercambiable con la recuperación del resultado de una tarea existente. Los errores de compatibilidad y la incertidumbre de transporte requieren manejos distintos.
Si la solicitud corregida es aceptada, continúa de acuerdo con el flujo de respuesta documentado para esa tarea. Algunas operaciones devuelven un resultado directamente; otras requieren recuperar el resultado. No inventes un ID de tarea ni comiences a hacer polling simplemente porque tu integración anterior siempre lo hacía.
Para problemas repetidos de presión de solicitudes, usa la referencia separada de solución de problemas de la API de CAPTCHA para identificar la condición realmente devuelta. Un tipo no soportado, un límite de tasa y un error de cuenta no son etiquetas diferentes para un mismo fallo.
Envía una reproducción compacta y redactada que muestre el aparente desajuste de contrato.
Incluye la URL de la documentación que seguiste, el tipo de tarea exacto, el endpoint, la versión del SDK o wrapper si interviene alguno, y el código de error completo y su descripción. Añade la hora de la solicitud con su zona horaria y un ID de tarea si está disponible.
Explica qué cambió: una actualización de paquete, una migración de proveedor, una nueva familia de CAPTCHA o un cambio en la configuración de despliegue. Esto da a soporte un punto de partida más estrecho que todo el registro de la aplicación.
No envíes secretos de cuenta ni una captura completa y autenticada del navegador por defecto. El objetivo es mostrar la operación no soportada y la forma relevante de la solicitud. Si se necesita más evidencia, proporciónala a través del proceso de soporte adecuado.
La guía existente sobre errores de tipo unsolvable cubre una etapa diferente: una tarea reconocida que no produjo una solución en ese intento. Úsala solo cuando ese sea el error que recibiste.
Repara primero el contrato de la tarea, luego prueba una solicitud acotada e inspecciona su resultado. La referencia actual de tareas de CapSolver debe ser la fuente de los nombres aceptados y los campos requeridos. Mantener esos nombres explícitos facilita la revisión de migraciones e investigaciones de soporte.
P: ¿Reintentar solucionará ERROR_TASK_NOT_SUPPORTED?
Un reintento sin cambios no corrige un tipo de tarea incorrecto o no soportado. Verifica el contrato y la solicitud efectiva antes de reenviar.
P: ¿Es lo mismo que ERROR_CAPTCHA_UNSOLVABLE?
No. El error de tarea no soportada se refiere al tipo solicitado. El error unsolvable se refiere a un intento que no reconoció el CAPTCHA. Lee la respuesta exacta antes de elegir la solución.
P: ¿Puedo usar un nombre de detección de SDK como task.type?
Solo si la referencia REST lista explícitamente ese valor. Las etiquetas de detección, los nombres de método del SDK y los nombres de herramientas MCP son conceptos de interfaces separados.
P: ¿Por qué apareció el error después de cambiar de proveedor?
Un cambio de proveedor puede dejar un identificador de tarea o un mapeo que pertenece al servicio anterior. Compara la solicitud final serializada con la referencia actual del proveedor de destino.
P: ¿Debo cambiar primero el sitekey?
No necesariamente. Primero determina si el tipo de tarea está soportado. Luego valida los campos específicos de la familia, incluida la URL de la página y el sitekey, contra el contrato documentado.
Aloísio Vítor
Image Processing Expert
Interpreting the visual signals behind web workflows.
SOBRE EL AUTOR
Soluciona el ERROR_IP_BANNED deteniendo las solicitudes repetidas y erróneas a la API de CAPTCHA, encontrando el primer error, revisando los códigos relacionados y reanudando con una prueba controlada.
Compare el reconocimiento de imágenes CAPTCHA y la resolución de tokens, comprende sus entradas y salidas y elige el flujo de trabajo de API adecuado para tu automatización autorizada.
