Como corrigir o erro ERROR_TASK_NOT_SUPPORTED em chamadas à API de CAPTCHA

Resumo

• ERROR_TASK_NOT_SUPPORTED significa que o tipo de CAPTCHA enviado está incorreto ou não é compatível com o serviço.
• Leia o task.type realmente enviado na requisição, não apenas o rótulo exibido em uma configuração de framework.
• Faça corresponder a família e a variante atuais do CAPTCHA exatamente ao tipo na referência oficial de tasks.
• Tipos de task da API REST, nomes de detecção em SDKs e nomes de ferramentas MCP pertencem a interfaces diferentes e não são intercambiáveis.
• Corrija a requisição incompatível antes de tentar novamente; reenvios idênticos não fazem um tipo de task passar a ser suportado.

Uma integração de CAPTCHA pode falhar antes mesmo de a etapa de reconhecimento começar. A API recebe uma requisição, examina seu tipo de task e rejeita uma operação que não suporta. Nessa situação, alterar a chave pública do site, esperar mais tempo ou aumentar o número de tentativas pode deixar o problema real intocado.

A CapSolver documenta ERROR_TASK_NOT_SUPPORTED separadamente de dados de task inválidos e de reconhecimentos malsucedidos. O caminho útil de troubleshooting é comparar a requisição que sua aplicação realmente envia com o contrato do serviço e da superfície de integração que você está usando.

O que ERROR_TASK_NOT_SUPPORTED indica

ERROR_TASK_NOT_SUPPORTED identifica um problema de compatibilidade de tipo de task; ele não indica que a imagem do CAPTCHA foi difícil ou que um token retornado expirou.

A referência oficial de códigos de erro define essa condição como um tipo de CAPTCHA incorreto ou não suportado. Preserve tanto errorCode quanto errorDescription ao revisar a falha. Uma mensagem genérica como “solver failed” perde a distinção necessária para escolher a correção adequada.

Comece com três fatos: qual endpoint recebeu a requisição, qual string de tipo exata ele recebeu e qual família de CAPTCHA estava presente na página. Estes são os elementos mínimos necessários para comparar sua implementação com a documentação.

Um parâmetro de API faz parte de um contrato de serviço. Um nome plausível não é necessariamente um nome suportado. Capitalização, ortografia, sufixos e variantes específicas de família devem vir da referência, não de um padrão de nomenclatura inferido de outro provedor.

Etapa 1: Inspecione a requisição serializada

Inspecione a requisição de saída depois que seu SDK, camada de configuração ou middleware a tiver transformado.

Uma tela de configurações pode dizer “reCAPTCHA v2”, enquanto o JSON final contém outra string. Uma variável de ambiente pode ainda guardar um valor aposentado. Um wrapper pode mapear um nome amigável para um identificador de task que já não corresponde ao serviço chamado. Leia o valor efetivo em vez de presumir que a configuração inicial chegou à API sem mudanças.

Para um cliente baseado em navegador, o painel Network do Chrome explica como inspecionar uma requisição e a resposta. Para código no servidor, use um registro de diagnóstico de escopo reduzido com segredos removidos. Evite registrar chaves de API, cookies de sessão, tokens completos ou dados de formulário não relacionados.

Registre o método, o host e caminho de destino, o tipo de task, os nomes de campo e o código e descrição da resposta. Inclua um ID de task apenas se o serviço realmente tiver retornado um. Uma falha na criação da task pode deixá-lo sem um identificador válido para consultar.

Verifique a forma do JSON separadamente

JSON sintaticamente válido não prova que uma task é suportada. A especificação JSON descreve um formato de dados; a referência de API define o significado permitido para seus campos.

Essa distinção ajuda quando um validador afirma que a requisição está bem formada, mas a API ainda a rejeita. Uma string sintaticamente correta pode mesmo assim nomear uma operação não suportada. Por outro lado, dados malformados merecem seu próprio diagnóstico, em vez de serem tratados como o mesmo erro.

Etapa 2: Faça corresponder o desafio atual ao task oficial

Combine a família e a variante atuais do CAPTCHA antes de selecionar um tipo de task substituto.

Use a visão geral dos tipos de task para localizar a família correta e, em seguida, abra a referência detalhada dessa família. Por exemplo, a referência de task do reCAPTCHA v2 lista os nomes de task v2 aceitos e seus campos. Copie o identificador a partir da entrada relevante, em vez de construí-lo de memória.

Verifique a página real novamente se a aplicação alterou recentemente sua integração de CAPTCHA. Uma configuração histórica pode descrever um provedor ou variante anteriores. A aparência do widget por si só não basta para provar que a task antiga ainda se aplica.

Também verifique a fronteira entre uma task de token e uma task de reconhecimento. Uma pode retornar um token para um fluxo de aplicação, enquanto a outra responde a uma requisição de reconhecimento de imagem. Tratar essas tasks como intercambiáveis apenas porque ambas envolvem CAPTCHA pode gerar o contrato de requisição errado.

Não experimente nomes de task aleatórios até que algum seja aceito. Isso obscurece a falha original e pode produzir uma operação diferente da que sua aplicação realmente precisa.

Resgate seu Código de Bônus CapSolver

Aumente instantaneamente seu orçamento de automação!
Use o código de bônus CAP26 ao recarregar sua conta CapSolver para ganhar 5% de bônus extra em cada recarga — sem limites.
Resgate agora no seu Painel CapSolver

Etapa 3: Mantenha separados os nomes de REST, SDK e MCP

Mantenha os nomes de cada superfície de integração na interface que os define.

Uma requisição REST envia um objeto de task. Um SDK pode expor métodos e valores de detecção normalizados. Um cliente MCP chama ferramentas nomeadas com seus próprios esquemas de entrada. Um nome retornado por uma camada não é automaticamente um task.type válido em outra.

Por exemplo, a referência do Core SDK explica seus métodos de navegador e resolução. Ao usar esse SDK, siga seus parâmetros documentados. Ao construir uma requisição REST diretamente, use a referência de tipos de task da REST. Ao usar MCP, inspecione o esquema da ferramenta em vez de colocar o nome da ferramenta em um campo de task da REST.

Isso é importante durante migrações. Substituir um pacote ou alterar um host de API pode deixar valores de configuração antigos no lugar. Mesmo serviços com envelopes de resposta semelhantes podem suportar identificadores de task e campos opcionais diferentes. Compare explicitamente os contratos de origem e destino.

Um recurso não suportado deve permanecer não suportado até que o provedor documente uma rota compatível. Não substitua silenciosamente uma família de desafios por outra apenas para fazer uma requisição passar pela validação.

Etapa 4: Corrija uma requisição antes de retomar a fila

Valide uma requisição corrigida antes de permitir que a mesma configuração chegue a todos os workers.

Primeiro interrompa a repetição automática da requisição já conhecida como incompatível. Depois corrija o descompasso específico que você identificou e faça um teste controlado. Revise o status e os campos retornados antes de reativar o fluxo mais amplo.

A orientação do HTTP sobre repetição de requisições não idempotentes é relevante quando uma falha de rede deixa incerto o resultado de uma operação. Não presuma que uma nova requisição de criação de task é intercambiável com a recuperação do resultado de uma task existente. Erros de compatibilidade e incerteza de transporte exigem tratamentos diferentes.

Se a requisição corrigida for aceita, prossiga de acordo com o fluxo de resposta documentado para aquela task. Algumas operações retornam um resultado diretamente; outras exigem a recuperação do resultado. Não invente um ID de task nem comece a fazer polling apenas porque sua integração anterior sempre fazia isso.

Para problemas recorrentes de pressão de requisições, use a referência de troubleshooting da API de CAPTCHA para identificar a condição realmente retornada. Um tipo não suportado, um limite de taxa e um erro de conta não são rótulos diferentes para a mesma falha.

O que enviar ao suporte se o tipo parecer correto

Envie uma reprodução compacta e redigida que mostre o aparente descompasso de contrato.

Inclua a URL da documentação que você seguiu, o tipo de task exato, o endpoint, a versão do SDK ou wrapper se um deles estiver envolvido, e o código e a descrição completos do erro. Adicione o horário da requisição com seu fuso horário e um ID de task se disponível.

Explique o que mudou: uma atualização de pacote, uma migração de provedor, uma nova família de CAPTCHA ou uma alteração de configuração de deploy. Isso oferece ao suporte um ponto de partida mais estreito do que todo o log da aplicação.

Não envie segredos de conta nem uma captura completa de navegador autenticado por padrão. O objetivo é mostrar a operação não suportada e o formato relevante da requisição. Se mais evidências forem necessárias, forneça-as pelo processo de suporte apropriado.

O guia existente sobre o erro “unsolvable” cobre uma fase diferente: uma task reconhecida que não produziu solução naquela tentativa. Use-o apenas quando esse for o erro recebido.

Construa fluxos de automação confiáveis com a CapSolver

Repare primeiro o contrato da task, depois teste uma requisição limitada e inspecione seu resultado. A referência atual de tasks da CapSolver deve ser a fonte de nomes aceitos e campos obrigatórios. Manter esses nomes explícitos torna migrações e investigações de suporte mais fáceis de revisar.

FAQ

P: Repetir a requisição vai corrigir ERROR_TASK_NOT_SUPPORTED?

Uma repetição sem mudanças não corrige um tipo de task incorreto ou não suportado. Verifique o contrato e a requisição efetiva antes de reenviar.

P: Isso é o mesmo que ERROR_CAPTCHA_UNSOLVABLE?

Não. O erro de task não suportada diz respeito ao tipo solicitado. O erro “unsolvable” diz respeito a uma tentativa que não reconheceu o CAPTCHA. Leia a resposta exata antes de escolher a correção.

P: Posso usar um nome de detecção de SDK como task.type?

Somente se a referência REST listar explicitamente esse valor. Rótulos de detecção, nomes de métodos de SDK e nomes de ferramentas MCP são conceitos de interface distintos.

P: Por que o erro apareceu depois de trocar de provedor?

Uma troca de provedor pode deixar um identificador de task ou mapeamento que pertence ao serviço anterior. Compare a requisição serializada final com a referência atual do provedor de destino.

P: Devo trocar o sitekey primeiro?

Não automaticamente. Primeiro determine se o tipo de task é suportado. Depois valide os campos específicos da família, incluindo a URL da página e o sitekey, em relação ao contrato documentado.