Encontrou enterprise.js no lugar de api.js? Quase nada muda do seu lado: as duas versões devolvem uma pontuação de 0,0 a 1,0 e o mesmo formato de token. O que o Google vende no Enterprise é console, política de risco e telemetria para quem defende o site.
Na automação, a diferença cabe em um parâmetro. Resumindo:
- O token continua chegando no campo
g-recaptcha-response. - Quem verifica o token troca
siteverifyporrecaptchaenterprise.googleapis.com. - Na requisição à CaptchaAI, basta somar
enterprise: 1.
Abaixo, por que os sites migram, como reconhecer cada versão e o que ajustar na sua integração.
Por que um site troca o Standard pelo Enterprise
A troca raramente é motivada pelo CAPTCHA em si; ela vem junto de uma reforma de segurança maior:
| Motivo | O que muda para o site |
|---|---|
| Integração com WAF | O reCAPTCHA conversa com Cloudflare/Akamai |
| Análise detalhada | Painel com tendências de risco e padrões de ataque |
| Regras personalizadas | Limites diferentes por ação (login, checkout) |
| Conformidade | Opções de SLA corporativo e residência de dados |
| Proteção de conta | Detecção de vazamento de senha e tomada de conta |
Nada nessa lista muda a natureza do desafio: o que muda é a régua aplicada depois da pontuação.
As diferenças lado a lado
Para quem automatiza, só duas linhas importam: o endpoint de verificação e a origem da sitekey.
| Recurso | Standard | Enterprise |
|---|---|---|
| Preço | Gratuito (até 1 milhão de avaliações/mês) | US$ 1 por 1.000 avaliações (1K–100K/mês), escalonado acima |
| Faixa de pontuação | 0,0–1,0 | 0,0–1,0 |
| Códigos de motivo | Não | Sim (AUTOMATION, UNEXPECTED_ENVIRONMENT, etc.) |
| Limites personalizados | Não (definidos no seu código) | Sim (por ação, no console) |
| Gerenciamento por projeto | Não | Sim (Google Cloud Console) |
| Endpoint de verificação | siteverify |
recaptchaenterprise.googleapis.com |
| Detecção de vazamento de senha | Não | Sim |
| Account Defender | Não | Sim |
| Autenticação multifator | Não | Sim (via WAF) |
| Suporte a v2 | Sim | Sim |
| Suporte a v3 | Sim | Sim |
O que a verificação devolve em cada versão
As duas respostas carregam a mesma pontuação, em lugares diferentes do JSON.
Resposta do Standard
{
"success": true,
"score": 0.7,
"action": "login",
"challenge_ts": "2024-01-15T12:00:00Z",
"hostname": "example.com"
}
A pontuação vem na raiz — o formato que as suítes antigas esperam.
Resposta do Enterprise
{
"tokenProperties": {
"valid": true,
"action": "login",
"createTime": "2024-01-15T12:00:00Z",
"hostname": "example.com"
},
"riskAnalysis": {
"score": 0.7,
"reasons": ["LOW_CONFIDENCE_SCORE"],
"extendedVerdictReasons": []
},
"event": {
"token": "...",
"siteKey": "...",
"expectedAction": "login"
}
}
O array reasons explica por que a pontuação ficou naquele valor. Para quem integra, isso se traduz em três ajustes concretos:
scorena raiz do JSON passa a serriskAnalysis.score.- A checagem de sucesso deixa de olhar
successe passa a olhartokenProperties.valid. - A ação esperada aparece em
event.expectedAction.
Como identificar o Enterprise no código da página
Confirme a versão antes de mexer na integração:
| Indicador | Standard | Enterprise |
|---|---|---|
| URL do script | google.com/recaptcha/api.js |
google.com/recaptcha/enterprise.js |
| Função de execução | grecaptcha.execute() |
grecaptcha.enterprise.execute() |
| API de verificação | endpoint siteverify |
recaptchaenterprise.googleapis.com |
| Console | console administrativo do reCAPTCHA | Google Cloud Console |
No código-fonte da página:
// Standard
<script src="https://www.google.com/recaptcha/api.js?render=SITEKEY"></script>
// Enterprise
<script src="https://www.google.com/recaptcha/enterprise.js?render=SITEKEY"></script>
No console do navegador, o teste é ainda mais rápido:
- O objeto
grecaptcha.enterpriseexiste? Então é Enterprise. - A tag de script aponta para
enterprise.js? Mesma conclusão. - Só
api.jsegrecaptcha.execute? É Standard, e sua chamada continua igual.
Integração com a CaptchaAI: um parâmetro de diferença
O método segue userrecaptcha, a sitekey vai em googlekey e o token volta como g-recaptcha-response. Muda só o sinalizador.
reCAPTCHA v3 Standard
resp = requests.get("https://ocr.captchaai.com/in.php", params={
"key": API_KEY, "method": "userrecaptcha", "version": "v3",
"googlekey": SITEKEY, "action": "login", "pageurl": URL, "json": 1
})
reCAPTCHA v3 Enterprise
resp = requests.get("https://ocr.captchaai.com/in.php", params={
"key": API_KEY, "method": "userrecaptcha", "version": "v3",
"enterprise": 1, # Only difference
"googlekey": SITEKEY, "action": "login", "pageurl": URL, "json": 1
})
reCAPTCHA v2 Standard
resp = requests.get("https://ocr.captchaai.com/in.php", params={
"key": API_KEY, "method": "userrecaptcha",
"googlekey": SITEKEY, "pageurl": URL, "json": 1
})
reCAPTCHA v2 Enterprise
resp = requests.get("https://ocr.captchaai.com/in.php", params={
"key": API_KEY, "method": "userrecaptcha",
"enterprise": 1,
"googlekey": SITEKEY, "pageurl": URL, "json": 1
})
Três detalhes derrubam a maioria das integrações recém-migradas:
- Reaproveitar a sitekey antiga: no Enterprise ela é outra, criada no Google Cloud Console.
- Esquecer o campo
actionno v3 — o site compara a ação declarada e recusa o token quando ela não bate. - Enviar o token depois do prazo de validade. Quando a demora está no navegador, o problema costuma ser o tempo entre a resolução e o envio do formulário, não o sinalizador.
Antes de abrir um chamado, repita a requisição com
json=1e guarde o ID da tarefa: boa parte dos casos de "Enterprise não funciona" é sitekey trocada.
Cenário: uma suíte de QA que quebra sem aviso
Um time em São Paulo valida o próprio checkout em staging.example.com. Depois de uma troca de WAF, o formulário passa a carregar enterprise.js: no navegador nada muda, mas as asserções que liam score em siteverify param de achar o campo. O reparo leva uma tarde:
- Aponte a asserção para
riskAnalysis.scoree paratokenProperties.valid. - Troque a sitekey do ambiente de testes pela nova, gerada no Google Cloud Console.
- Some
"enterprise": 1à chamada da CaptchaAI e rode a suíte inteira, não só o caso de login.
O sintoma clássico é a suíte "verde" no navegador e vermelha na asserção: o token chega, a leitura do JSON é que mudou de lugar.
Aproveite para revisar o log da suíte: a LGPD alcança o conteúdo do formulário, não o token. Pontuação e ID da tarefa bastam para depurar; CPF e e-mail digitados no teste, não.
Checklist antes de mexer na integração
- Abra o HTML e confirme se o script é
api.jsouenterprise.js. - Copie a sitekey da página em uso — nunca a do console antigo.
- Ajuste o parser da verificação para
riskAnalysis.scorequando for Enterprise. - Some
enterprise: 1à chamada e valide um caso de v2 e um de v3. - Rode a suíte duas vezes: erros de expiração aparecem sob carga.
Perguntas frequentes
O parâmetro enterprise vale para v2 e v3?
Sim. É independente da versão: combine enterprise: 1 com version: v3 ou envie sem version no v2.
Resolver Enterprise custa mais caro na CaptchaAI?
Não há sobretaxa por tipo. A cobrança é por thread simultânea: o BASIC custa US$ 15/mês com 5 threads e resoluções ilimitadas.
Quais tipos a CaptchaAI cobre além do reCAPTCHA?
Cloudflare Turnstile e Challenge, GeeTest v3, imagem/OCR e desafios de grade, além de CaptchaFox (beta), Friendly Captcha (beta) e Lemin (beta). O hCaptcha não é suportado, em nenhuma variante.
A sitekey do Standard serve no Enterprise?
Não. As sitekeys Enterprise nascem no Google Cloud Console e são distintas das do console clássico — quando um site migra, a chave antiga deixa de valer.
O token voltou, mas o site recusou. O que verificar primeiro?
Compare a action enviada com a que a página declara e confira se a sitekey é a do console novo. Só depois olhe o prazo: o token vale poucos minutos e precisa ir ao formulário logo após a resolução.
Guias relacionados
Para aprofundar a identificação da versão: