Resposta curta: seu token provavelmente está correto. A nota baixa diz que o Google avaliou a origem da requisição e o comportamento da sessão — não a sua integração. É isso que torna a v3 desconfortável de depurar: sem imagem para clicar e sem mensagem de erro, a suspeita cai sobre o único trecho visível — o seu código.
O que a nota realmente mede
A v3 devolve um número entre 0,0 (típico de bot) e 1,0 (típico de pessoa). O corte é decisão de cada site — checkout costuma exigir 0,7; cadastro passa com 0,3 — e você não controla esse limite.
| Categoria de sinal | O que é observado |
|---|---|
| Reputação de IP | Datacenter ou rede comum, histórico de abuso |
| Sinais do navegador | Canvas, WebGL, fontes, plug-ins |
| Cookies e sessão | Cookies do Google, histórico de navegação |
| Movimento do mouse | Trajetória, velocidade, pausas |
| Rolagem e digitação | Padrão de rolagem, ritmo entre teclas |
| Tempo de permanência | Tempo na página antes da ação |
| Frequência de envio | Execuções partindo da mesma sessão |
O ponto que quase todo diagnóstico erra: nenhum sinal isolado derruba a nota. O que derruba é a soma — IP de datacenter mais perfil sem histórico mais envio instantâneo.
Monte o loop de medição antes de mexer em qualquer coisa
Sem medição você troca a origem de rede, troca o perfil e não sabe o que mexeu no número. Em ambiente próprio, registre a nota do siteverify a cada envio; em uma dúzia de rodadas o padrão aparece. Se esse log guardar IP ou identificadores de sessão, considere as obrigações da LGPD (ou do RGPD, em Portugal).
Antes de tudo, confirme que a sitekey é mesmo a da v3 e não a de um widget v2 na mesma página. Depois altere uma variável por vez, nesta ordem de impacto: origem de rede, idade do token, perfil do navegador, frequência de envio, cookies de sessão. Se a API responde bem e só o fluxo pelo navegador falha, o problema está no ambiente da automação.
As sete causas mais frequentes
1. Reputação de IP: a explicação mais comum para o score travado em 0,1
O Google mantém histórico por faixa de endereços: saídas de datacenter compartilhadas já chegam com nota reduzida antes de a página abrir.
Como corrigir: use egress de rede autorizado e dedicado, com rotação entre execuções.
2. Parâmetro de ação divergente
Toda chamada grecaptcha.execute() carrega uma string de ação — login, submit, checkout — embutida no token. Se ela não bate com a esperada, o backend descarta a verificação mesmo com nota alta.
Como corrigir: no DevTools, copie o valor exato para o parâmetro action. Maiúsculas contam.
3. Perfil de navegador sem história
Um navegador headless recém-iniciado não tem nada a apresentar: nenhum movimento de mouse, nenhuma rolagem, nenhum cookie.
Como corrigir: reaproveite um perfil persistente, reproduza interação real antes do envio e use viewport e user agent de desktop comum.
4. Cookies do Google ausentes
Cookies como NID, SID e HSID carregam histórico que o modelo lê como uso legítimo; perfis criados do zero não têm nenhum deles.
Como corrigir: parta de um perfil com sessão do Google válida antes de abrir a página com o CAPTCHA.
5. Token consumido tarde demais
O token da v3 vale 2 minutos. Pipelines que resolvem cedo e só enviam depois de outras validações estouram esse limite: funciona local e quebra no CI.
Como corrigir: peça o token como último passo antes do POST.
6. Muitas execuções na mesma sessão
Chamadas repetidas de grecaptcha.execute() na mesma sessão reduzem a nota a cada rodada.
Como corrigir: espace as requisições em 15 a 30 segundos e alterne sessões e perfis entre lotes.
7. Modo headless identificável
Sites reconhecem o Chrome headless por propriedades inconsistentes de chrome.runtime e pela ausência de plug-ins que um navegador comum declara.
Como corrigir: rode uma instância real do navegador, com configuração padrão, e valide em staging.
Um cenário de QA no Brasil
Um time em São Paulo mantém workers em sa-east-1 e homologação na Europa. Depois de migrar para uma faixa de IP de datacenter recém-alocada, todo envio da v3 passou a voltar em 0,1.
Dois fatores somados: a faixa era nova para o modelo, sem histórico a favor, e o RTT entre São Paulo e a região do alvo, mais dois passos de validação antes do POST, consumia boa parte dos 2 minutos do token. Isolando um fator por vez em ambiente próprio, com dados fictícios e URLs de staging, o time viu que apenas pedir o token por último já recuperava parte da nota.
O que esperar da CaptchaAI na v3
A CaptchaAI resolve reCAPTCHA v3 em ambientes de navegador reais e devolve tokens que normalmente pontuam 0,3 — suficiente para a maioria dos sites, insuficiente acima disso. A nota continua sendo do Google: nenhum serviço escolhe o score, apenas emite o token em condições melhores que as de um worker headless recém-criado.
O fluxo é igual em Python e Node.js: envie a sitekey, a pageurl e a ação exata para in.php e consulte res.php até o token voltar.
import requests
import time
response = requests.get("https://ocr.captchaai.com/in.php", params={
"key": "YOUR_API_KEY",
"method": "userrecaptcha",
"version": "v3",
"googlekey": "SITE_KEY",
"action": "login",
"pageurl": "https://staging.example.com/qa-login",
"json": 1
})
task_id = response.json()["request"]
for _ in range(30):
time.sleep(5)
result = requests.get("https://ocr.captchaai.com/res.php", params={
"key": "YOUR_API_KEY", "action": "get", "id": task_id, "json": 1
}).json()
if result.get("status") == 1:
token = result["request"]
print(f"Token received: {token[:50]}...")
break
const axios = require('axios');
async function solveV3(sitekey, pageurl, action) {
const { data } = await axios.get('https://ocr.captchaai.com/in.php', {
params: {
key: 'YOUR_API_KEY', method: 'userrecaptcha', version: 'v3',
googlekey: sitekey, action, pageurl, json: 1
}
});
const taskId = data.request;
for (let i = 0; i < 30; i++) {
await new Promise(r => setTimeout(r, 5000));
const res = await axios.get('https://ocr.captchaai.com/res.php', {
params: { key: 'YOUR_API_KEY', action: 'get', id: taskId, json: 1 }
});
if (res.data.status === 1) return res.data.request;
}
throw new Error('Timeout');
}
Perguntas frequentes
Qual score o site exige para aceitar meu token?
Não dá para ler o corte de fora — ele fica no backend do site. Dá para inferir: se tokens de 0,3 passam, o limite é 0,3 ou menor. Registre a nota do siteverify a cada envio e o valor fica evidente.
Na minha máquina a nota é alta e no CI cai para 0,1. O que muda?
Muda o ambiente, não o código. O CI roda em faixa de datacenter, com navegador recém-criado e sem cookie do Google — três sinais fracos de uma vez. Reproduza o cenário do CI localmente antes de mexer na integração.
O token da v3 tem tempo de vida diferente do da v2?
Sim, e é o detalhe que mais quebra pipeline: o da v3 vale 2 minutos. Se houver validações intermediárias antes do POST, cronometre esse trecho no CI antes de culpar o score.
Preciso de plano pago só para validar a integração?
O plano BASIC (US$ 15/mês, 5 threads) cobre validação e QA. A cobrança é por thread concorrente, com resoluções ilimitadas nas threads contratadas — repetir a suíte não aumenta o custo. Acima dele vêm STANDARD (US$ 30/mês, 15 threads) e ADVANCE (US$ 90/mês, 50 threads).
Vale insistir na v3 ou resolver o fallback v2?
Depende do corte do site. Muitos exibem um desafio v2 justamente quando a nota da v3 fica baixa, e a v2 tem resultado binário — se a v3 reprova sempre, o fallback é mais previsível.
