Há alguns meses, um desenvolvedor no Stack Overflow fez uma pergunta que continua aberta desde 2012: "Google Places API Place Details limitado a 5 avaliações?" Quatorze anos e centenas de votos positivos depois, a resposta ainda é a mesma — sim, no máximo cinco avaliações. Essa limitação, por si só, já mostra por que esse debate continua existindo.
Se você já precisou de dados do Google Places em grande escala — listas de leads, avaliações de concorrentes, padrões de fluxo de clientes, auditorias de SEO local — provavelmente também chegou a essa encruzilhada. A API oficial do Google Places é limpa, estruturada e bem documentada. Mas ela não devolve tudo o que você vê numa página do Google Maps, e a conta pode ficar salgada quando você passa da camada gratuita. O scraping puxa mais informações, tem uma lógica de custo diferente e traz seus próprios problemas (CAPTCHAs, seletores quebrados, áreas cinzentas no aspecto legal). Passei bastante tempo analisando os dois lados — a documentação da API, os SKUs de preço, o ecossistema de scraping e as trocas reais envolvidas — e este artigo é o resultado. Vamos cobrir lacunas de dados campo a campo, custos reais em 10 mil/100 mil/1 milhão de registros, a realidade do anti-bot e um playbook híbrido prático. E também tem um fluxograma de decisão, porque ninguém quer ler 3.000 palavras e ainda sair sem saber o que escolher.
O que é a Google Places API (e o que ela realmente entrega)?
A Google Places API é a forma oficial e estruturada do Google entregar dados de empresas — nomes, endereços, telefones, avaliações, fotos — a partir da base deles. Você manda uma requisição HTTP e recebe JSON formatado. É o caminho oficial.
A versão atual (Places API "New") organiza tudo com base em field masks. Quando você chama Place Details, você informa exatamente quais campos quer — displayName, formattedAddress, rating, reviews, photos etc. — e o Google cobra com base na faixa mais alta dos campos solicitados. Se você omitir a field mask, recebe erro, não uma resposta padrão. Isso é proposital: o Google quer que você pague só pelo que usa (e cobre mais pelos dados mais valiosos).
Os campos disponíveis são organizados por faixas de preço:
| Faixa | Campos de exemplo | O que você recebe |
|---|---|---|
| Essentials | Place ID, endereço formatado, localização, metadados de fotos | Identidade básica e localização |
| Pro | Nome de exibição, status da empresa, URI do Google Maps, tipo principal | Informações comerciais mais completas |
| Enterprise | Avaliação, quantidade de avaliações, site, telefones, horário de funcionamento, nível de preço | Os campos que a maioria dos usuários de negócio realmente quer |
| Enterprise + Atmosphere | Avaliações, resumo de avaliações, resumo gerado por IA, comodidades, estacionamento, retirada/entrega | Os dados mais ricos (e mais caros) |
Os principais endpoints que a maioria das pessoas procura são: Autocomplete (para busca enquanto digita), Text Search e Nearby Search (para descobrir lugares), Place Details (para enriquecer um local já conhecido) e Place Photos (para imagens).
Agora, as limitações que realmente importam:
- Avaliações: o recurso Place retorna no máximo 5 avaliações por local, ordenadas por relevância. Só isso. Não são 50, nem "todas". Cinco.
- Fotos: limitado a 10 referências de fotos por local no recurso Place.
- Horários de pico / movimento em tempo real: não estão disponíveis como campo padrão da Places API. O Google confirma que esses dados existem nas superfícies voltadas ao consumidor (com base em Histórico de Localização agregado e anonimizado), e o blog do Maps explica como isso funciona — mas a lista de campos não inclui isso.
- Seção de perguntas e respostas: não é exposta.
- Concorrentes em "as pessoas também pesquisam por": não é exposto.
- Cardápio / tabela de preços: não é um campo padrão.
Quem normalmente usa a Google Places API?
- Empresas de logística validando e geocodificando endereços
- Apps de turismo e hospitalidade mostrando hotéis, restaurantes e atrações próximos
- Plataformas imobiliárias enriquecendo imóveis com dados de negócios locais
- Agências de SEO local auditando consistência de NAP (nome, endereço, telefone)
- Equipes de vendas montando listas de leads a partir de Place IDs e informações básicas de empresas
Se o seu caso de uso se encaixa em "preciso de dados estruturados de locais em um app de produção", a API é o ponto de partida certo. Se o seu caso envolve as palavras "todas as avaliações", "horários de pico" ou "análise de concorrentes" — continue lendo.
O que significa "scraping" de dados do Google Places?
Web scraping é usar software para extrair automaticamente dados de uma página da web — neste caso, do Google Maps ou dos resultados do Google Search — em vez de usar uma API oficial. O scraper lê a página do mesmo jeito que o seu navegador lê e então coleta os trechos estruturados: nome da empresa, endereço, texto das avaliações, nota média, histogramas de horários de pico, perguntas e respostas, sugestões de concorrentes, a galeria completa de fotos e qualquer outro conteúdo que apareça na tela.
A diferença principal: a API entrega o que o Google decide expor. O scraping entrega, em teoria, tudo o que uma pessoa consegue ver na página.
Mas "scraping" não é uma coisa só. Existem três abordagens bem diferentes, e as trocas entre elas são importantes.
Scripts próprios vs. APIs de scraping gerenciadas vs. ferramentas sem código
| Abordagem | Como funciona | Melhor para | Principal troca |
|---|---|---|---|
| Scripts próprios (Puppeteer, Playwright, Selenium) | Você escreve e mantém um script com navegador headless que navega pelas páginas do Google Maps e analisa o DOM | Desenvolvedores que precisam de controle total e lógica personalizada | Maior esforço de manutenção — seletores quebram quando o Google muda a interface |
| APIs de scraping gerenciadas (Thunderbit API, SerpApi, Outscraper) | Você envia uma URL ou consulta para uma API; ela cuida de renderização, anti-bot e parsing, e devolve dados estruturados | Desenvolvedores que querem saída estruturada sem manter scrapers | Preço e qualidade variam; você depende de terceiros |
| Extensões de navegador sem código (Thunderbit Chrome Extension) | Extração por clique no navegador — a IA sugere campos, você clica em "Scrape" e exporta para Sheets/Excel | Usuários de negócio, marketing e vendas que precisam de dados rápido em planilha | Menos flexível para pipelines complexos; depende da qualidade da IA da ferramenta |
Resumo curto: DIY = mais flexível, mas muito mais manutenção. APIs gerenciadas = saída estruturada, sem manutenção. Ferramentas sem código = o caminho mais rápido para quem não é desenvolvedor.
Google Places API vs. scraping: comparação campo a campo
Esta é a tabela que eu gostaria de ter encontrado quando comecei a pesquisar o tema. Todo campo que um usuário de negócio ou desenvolvedor pode precisar, comparado lado a lado:

| Campo de dados | Google Places API | Web Scraping |
|---|---|---|
| Nome da empresa | ✅ Completo (faixa Pro) | ✅ Completo |
| Endereço / localização | ✅ Completo (faixa Essentials) | ✅ Completo |
| Telefone | ✅ Faixa Enterprise | ✅ Quando visível |
| URL do site | ✅ Faixa Enterprise | ✅ Quando visível |
| Avaliação média | ✅ Faixa Enterprise | ✅ Completa |
| Quantidade de avaliações | ✅ Faixa Enterprise | ✅ Completa |
| Avaliações individuais (texto + nota) | ⚠️ Máximo de 5 avaliações | ✅ Todas as avaliações disponíveis |
| Horários de pico / movimento em tempo real | ❌ Não é um campo padrão da API | ✅ Extraível (quando renderizado) |
| Seção de perguntas e respostas | ❌ Não exposta | ✅ Extraível |
| Metadados de fotos | ✅ Máximo de 10 referências via endpoint Photos | ✅ Galeria completa |
| Cardápio / tabela de preços | ❌ Não é um campo padrão | ⚠️ Quando aparece na página |
| "As pessoas também pesquisam por" (concorrentes) | ❌ Não exposto | ✅ Extraível |
| Horário de funcionamento | ✅ Faixa Enterprise | ✅ Quando visível |
| Nível de preço | ✅ Faixa Enterprise | ✅ Quando visível |
| Place ID | ✅ Forte (Essentials) | ⚠️ Possível, mas a API é a fonte canônica |
| URI do Google Maps | ✅ Faixa Pro | ✅ É a URL da página |
| Respostas do proprietário às avaliações | ⚠️ Verificar disponibilidade atual | ✅ Frequentemente visíveis |
| Posição na SERP / no mapa local | ❌ Não é o propósito da API | ✅ Via scraping de SERP |
A principal lacuna: se você precisa de conjuntos completos de avaliações para análise de sentimento, monitoramento de reputação ou benchmarking competitivo, a API sozinha não resolve. Cinco avaliações por local é uma amostra, não um conjunto de dados.
Horários de pico e padrões de fluxo de clientes? Mesma história. Se você é consultor de varejo ou analista de imóveis comerciais, o scraping é o único caminho — esses dados simplesmente não estão na API.
Por outro lado, para Place IDs canônicos, endereços estruturados para geocoding ou para alimentar um localizador de lojas, a API é mais limpa, mais confiável e oficialmente suportada.
O custo real: Google Places API vs. scraping em 10 mil, 100 mil e 1 milhão de registros
O custo é a parte mais mal interpretada dessa decisão. Muita gente se inscreve na camada gratuita da API, cria um protótipo e depois leva um susto quando começa a escalar. No lado do scraping, muita gente subestima o custo de proxy e o tempo de desenvolvimento.

Vamos à conta.
Detalhamento de preços da Google Places API
Em março de 2025, o Google reformulou os preços da Maps Platform, trocando o antigo crédito fixo mensal de $200 por limites gratuitos por SKU e faixas por volume. O preço atual funciona assim:
- Campos Essentials (Place Details): 10.000 requisições grátis por mês, depois US$ 5,00 por 1.000 até 100 mil
- Campos Pro (Place Details): 5.000 grátis, depois US$ 7,00 por 1 mil
- Campos Enterprise (Place Details): 1.000 grátis, depois US$ 20,00 por 1 mil
- Enterprise + Atmosphere (avaliações, comodidades): 1.000 grátis, depois US$ 25,00 por 1 mil
Detalhe crítico: se a sua field mask incluir até mesmo um único campo de Enterprise + Atmosphere (como reviews), toda a requisição é cobrada nessa faixa. E um fluxo típico encadeia vários SKUs — Text Search Pro para descobrir locais e depois Place Details Enterprise + Atmosphere para enriquecê-los — então os custos vão somando.
Uma única "consulta" raramente significa uma única requisição faturável.
Custos de scraping: ferramentas, proxies e tempo de desenvolvimento
Os custos de scraping se dividem em três blocos:
- Assinatura da ferramenta ou créditos de API: APIs de scraping gerenciadas cobram por requisição, por crédito ou por registro. A SerpApi cobra por busca. A Outscraper usa pagamento conforme o uso por registro. A API da Thunderbit usa um sistema de créditos (Extract = 20 créditos/requisição). A extensão Chrome da Thunderbit cobra 1 crédito por linha de saída.
- Gasto com proxy (apenas DIY): proxies residenciais para scraping do Google Maps normalmente custam entre US$ 50 e US$ 300/mês, dependendo do volume e do provedor.
- Tempo de desenvolvimento (apenas DIY): construir e manter scripts em Puppeteer/Playwright. Esse é o custo oculto que acaba com a economia do DIY (mais sobre isso abaixo).
Tabela lado a lado: API vs. scraping em escala
| Escala | Google Places API (Enterprise + Atmosphere) | API de scraping gerenciada (estim.) | Scraping DIY (proxy + tempo de dev) |
|---|---|---|---|
| 10 mil registros/mês | ~US$ 225 (1 mil grátis, 9 mil × US$ 25/1 mil) | ~US$ 50–US$ 150, dependendo do provedor | ~US$ 50 de proxy + 2–4 horas de dev/mês |
| 100 mil registros/mês | ~US$ 2.475 (após a franquia grátis, entram as faixas por volume) | ~US$ 250–US$ 500 | ~US$ 150 de proxy + 8–16 horas de dev/mês |
| 1 milhão de registros/mês | ~US$ 17.975 (as faixas por volume reduzem o custo unitário, mas o total ainda é alto) | ~US$ 1.500–US$ 3.000 | ~US$ 300 de proxy + 20+ horas de dev/mês + risco de quebra |
Observações: as estimativas da API usam as faixas de volume publicadas para Place Details Enterprise + Atmosphere, aplicadas após a franquia grátis de 1 mil. As estimativas de API de scraping gerenciada são faixas aproximadas entre provedores. O tempo de desenvolvimento no DIY considera custo carregado de US$ 50–US$ 100/h.
O padrão é claro: em escala pequena (abaixo de 10 mil), os limites gratuitos da API podem torná-la a opção mais barata, especialmente se você só precisa de campos Essentials ou Pro. Em escala de negócio (100 mil+), os custos da API sobem rápido, principalmente para campos ricos. Em escala corporativa (1 milhão+), a API pode chegar a cinco dígitos por mês, e serviços de scraping ou datasets passam a fazer muito mais sentido economicamente — desde que você realmente precise dos campos extras que a API não expõe.
Se você só precisa de endereços e Place IDs, não faça scraping. A API é mais barata e melhor para isso. O argumento de custo a favor do scraping só vale quando você precisa de dados que a API não entrega.
A realidade do anti-bot: por que scrapers DIY para Google quebram
Aqui está a parte que quem gosta de scraping costuma pular. O Google não quer que você faça scraping do Google Maps. Eles montaram várias camadas de defesa e as atualizam com frequência.

As defesas em camadas do Google
- Desafios de reCAPTCHA: navegadores automatizados acionam CAPTCHAs com muito mais frequência do que usuários humanos
- Renderização JavaScript no lado do cliente: o Google Maps é uma aplicação JavaScript pesada. Uma simples requisição HTTP não traz o conteúdo renderizado — você precisa de um navegador headless completo
- Fingerprint de navegador: o Google identifica navegadores headless por fingerprints de canvas, WebGL, propriedades de navigator e outros sinais
- Limitação por IP: muitas requisições do mesmo IP (ou da mesma sub-rede de proxy) e você é bloqueado
- Mudanças na estrutura do DOM: o Google altera a forma como suas páginas são construídas com frequência — o consenso em Reddit e em issues do GitHub é que os seletores quebram a cada poucas semanas ou meses
Esse último ponto é o assassino silencioso. Um script em Puppeteer que funcionava perfeitamente em junho pode devolver resultados em branco em julho porque o Google renomeou uma classe CSS ou reorganizou um div.
O custo oculto de manter scripts próprios
Sempre que o Google muda o DOM, alguém do seu time precisa:
- Perceber que o scraper quebrou (de preferência antes que dados ruins se espalhem)
- Inspecionar a nova estrutura da página
- Atualizar seletores, lidar com novos tipos de CAPTCHA e ajustar a lógica de retry
- Testar e publicar de novo
Ao longo de um ano, esse tempo de manutenção pode facilmente ultrapassar o custo de assinatura de uma API de scraping gerenciada. Já vi equipes gastarem mais de 40 horas de desenvolvimento por ano só para manter um scraper do Google Maps funcionando — e isso é uma estimativa conservadora para uma configuração moderadamente complexa.
Por que existem APIs de scraping gerenciadas
É exatamente por causa desse peso de manutenção que existem serviços como a API da Thunderbit, SerpApi e Outscraper. Eles absorvem a complexidade do anti-bot — renderização JS, solução de CAPTCHA, rotação de proxies, manutenção de seletores — e devolvem dados estruturados.
O endpoint POST /extract da Thunderbit com renderMode: "full" lida com páginas pesadas em JavaScript como o Google Maps e retorna JSON estruturado compatível com schema, não HTML bruto que ainda precisa ser parseado. O servidor MCP amplia isso para agentes de IA — Claude, Cursor ou outros fluxos baseados em LLM podem coletar dados do Google Maps durante a tarefa sem sair do próprio ambiente.
Para usuários não técnicos, a Thunderbit Chrome Extension é a opção sem manutenção: abra uma página do Google Maps, clique em "AI Suggest Fields", clique em "Scrape" e exporte para o Sheets. Sem seletores, sem proxies, sem depuração.
SerpApi e Outscraper são alternativas sólidas, com modelos de preço e formatos de saída diferentes. A SerpApi retorna JSON estruturado por busca; a Outscraper cobra por registro com preço conforme o uso. A escolha certa depende do seu volume, orçamento e de você precisar de JSON estruturado ou aceitar uma saída semiestruturada.
O playbook híbrido: usando Google Places API e scraping juntos
Nenhum dos artigos mais bem posicionados sobre esse tema sugere o que eu vejo funcionar melhor na prática: usar os dois. Muitas equipes acabam dependendo da API oficial para algumas tarefas e do scraping para outras. O segredo é casar a ferramenta certa com a tarefa certa.

Quando a API oficial vence
- Autocomplete em um app de produção ao vivo: baixa latência, compatível com os termos, confiável. Não tem discussão.
- Backends de apps baseados em localização: localizadores de lojas, validação de endereço, correspondência de Place IDs. A API é estruturada, suportada e documentada.
- Integrações sensíveis a compliance: contratos enterprise, produtos públicos ou qualquer contexto em que cumprir os termos do Google é inegociável.
Quando o scraping vence
- Extração completa de avaliações (mais de 5 mil avaliações por local): análise de sentimento, monitoramento de reputação, benchmarking competitivo. O limite de 5 avaliações da API torna isso inútil.
- Extração única de lista de leads: mais barato para jobs em lote sem cobrança recorrente. Uma ferramenta sem código como a Thunderbit pode coletar uma lista de empresas e exportar para planilha em minutos.
- Análise de horários de pico / fluxo de clientes: não disponível via API. Ponto final.
- Dados de perguntas e respostas e "as pessoas também pesquisam por" de concorrentes: só aparecem na página, não na API.
Quando uma abordagem híbrida faz sentido
- Monitoramento contínuo de preço/nota: use a API para dados estruturados básicos (Place ID, endereço, avaliação média) e depois faça scraping dos campos profundos que a API não cobre (avaliações completas, horários de pico).
- Fluxos de enriquecimento: use a API para obter Place IDs e informações canônicas da empresa, depois faça scraping das páginas individuais para conjuntos completos de avaliações, Q&A e contexto competitivo.
- Monitoramento programado: o scraper agendado da Thunderbit (para usuários sem código) ou a extração em lote via CLI com cron (para desenvolvedores) podem cuidar do scraping recorrente sem infraestrutura personalizada.
Matriz de decisão por caso de uso
| Caso de uso | Método recomendado | Por quê |
|---|---|---|
| Autocomplete em um app ao vivo | ✅ API oficial | Baixa latência, compatível com os termos, confiável |
| Coletar conjuntos completos com mais de 5 mil avaliações | ✅ Scraping / API de scraping | A API limita a 5 avaliações por local |
| Lista única de leads de negócios locais | ✅ Scraping (ou extensão da Thunderbit) | Mais barato em lote; sem cobrança recorrente |
| Análise de horários de pico / fluxo de clientes | ✅ Apenas scraping | Não disponível via API |
| Monitoramento contínuo de preço/nota | ⚠️ Híbrido | API para dados básicos, scraping para campos profundos |
| Backend de app baseado em localização | ✅ API oficial | Estruturada, suportada, com SLA |
| Rastreamento de posição na SERP de SEO local | ✅ Scraping / SERP API | Não é o propósito da Places API |
| "As pessoas também pesquisam por" de concorrentes | ✅ Apenas scraping | Não exposto via API |
Fluxograma de decisão: Google Places API vs. scraping — qual você deve escolher?
Em vez de um vago "depende", aqui vai um framework de decisão concreto. Passe por estas quatro perguntas:
1. Você precisa de dados em tempo real em um app de produção? → Sim: use a API oficial. Ela é suportada, tem SLA e está em conformidade com os termos. Pare por aqui. → Não: continue.
2. Você precisa de dados que a API não entrega (avaliações completas, horários de pico, Q&A)? → Sim: scraping é obrigatório. A API simplesmente não consegue fornecer esses dados. → Não: continue.
3. Quantos registros por mês? → Abaixo de 10 mil: a API provavelmente é a mais barata, especialmente se você só precisa de campos Essentials ou Pro. As franquias gratuitas cobrem bastante nessa escala. → Acima de 10 mil: scraping ou uma API de scraping gerenciada tende a ser mais econômico, especialmente para campos ricos.
4. Você tem recursos de desenvolvimento para construir e manter scrapers? → Sim: DIY com Puppeteer/Playwright dá controle máximo (mas reserve orçamento para manutenção contínua). → Não: use uma API de scraping gerenciada (Thunderbit API, SerpApi, Outscraper) ou uma ferramenta sem código (Thunderbit Chrome Extension).
Comparação rápida de alternativas voltadas para desenvolvedores
| Ferramenta | Modelo de preço | Formato de saída | Lida com anti-bot | Suporte a lote |
|---|---|---|---|---|
| Thunderbit API / MCP | Baseado em créditos (Extract = 20 créditos/requisição) | JSON estruturado compatível com schema | ✅ Renderização JS, rotação de proxy, geo-routing | ✅ Até 100 URLs por lote |
| SerpApi | Por busca (planos em camadas) | JSON estruturado | ✅ | ✅ Via parâmetros da API |
| Outscraper | Por registro (pagamento conforme uso) | JSON / CSV | ✅ | ✅ Via filas de tarefas |
| DIY (Puppeteer/Playwright) | Proxy + tempo de dev | HTML bruto (você faz o parse) | ❌ Você precisa cuidar disso | ✅ O que você conseguir construir |
O diferencial da API da Thunderbit: ela retorna JSON estruturado compatível com schema, com base em um JSON Schema que você define — não HTML ou Markdown bruto que ainda precisa ser processado. Se você alimenta um pipeline de LLM ou carrega dados em um banco, isso economiza tempo real de pós-processamento.
Onde a Thunderbit entra nisso tudo (para usuários de negócio e desenvolvedores)
Criamos a Thunderbit para fazer a ponte entre "preciso de dados do Google Maps" e "não quero virar engenheiro de infraestrutura de scraping". Veja como ela funciona para os dois públicos.
Para quem não é técnico: a extensão Chrome
- Abra uma página do Google Maps — uma página de resultados de busca ou um perfil individual de empresa
- Clique em "AI Suggest Fields" — a IA da Thunderbit lê a página e sugere colunas (nome da empresa, endereço, avaliação, avaliações, telefone etc.)
- Clique em "Scrape" — a extensão extrai os dados em uma tabela estruturada. Use o modo cloud para até 50 páginas em paralelo
- Faça scraping de subpáginas — clique em "Scrape Subpages" para visitar cada perfil e puxar os detalhes completos
- Exporte — para Excel, Google Sheets, Airtable ou Notion. Exportação gratuita, sem paywall
Para monitoramento recorrente — checagens semanais de nota de concorrentes, novas listagens de empresas — o scraper agendado roda automaticamente na frequência que você definir.
Para desenvolvedores: API, servidor MCP e CLI
POST /extractcom um JSON Schema: envie uma URL do Google Maps, defina os campos desejados e receba JSON estruturado. UserenderMode: "full"para páginas pesadas em JavaScript. A Thunderbit cuida da renderização, anti-bot, rotação de proxies e geo-routing.POST /distill: obtém Markdown limpo de qualquer página — útil para pipelines de LLM que precisam do conteúdo bruto, e não de campos estruturados. Custa 1 crédito/requisição contra 20 do Extract.- Servidor MCP: agentes de IA (Claude, Cursor) podem coletar dados do Google Maps durante a execução. Suporta distill, extração estruturada, sugestão de campos e jobs em lote de até 100 URLs.
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsonpara scraping agendado ou integrado a CI/CD.
Preço em créditos: Extract = 20 créditos/requisição, Distill = 1 crédito/requisição. Os créditos da API são por requisição, não por linha (ao contrário da extensão, em que 1 crédito = 1 linha de saída). Consulte os preços da Thunderbit para os planos atuais.
Considerações legais e de termos de uso
Vou ser breve e direto — sem terrorismo, sem pitch de vendas.
A Google Places API vem com termos claros: os termos específicos do serviço do Google dizem que o conteúdo da Places API pode ser usado sem um Google Map, mas não deve ser usado com um mapa que não seja do Google. Valores de latitude/longitude podem ser armazenados em cache por até 30 dias corridos consecutivos; Place IDs podem ser armazenados indefinidamente. Atribuição é obrigatória para detalhes, fotos e avaliações.
Fazer scraping do Google Maps pode violar os Termos de Serviço do Google. A aplicação varia — os riscos incluem bloqueio de IP, barreiras de CAPTCHA e, em casos raros, ação legal. APIs de scraping gerenciadas normalmente assumem parte do peso de conformidade em nome do usuário, mas isso não é um escudo jurídico.
Para apps de produção voltados ao usuário final, a API oficial é a opção mais segura. Para pesquisa interna, análise em lote e inteligência competitiva, scraping é prática comum de mercado. Consulte seu próprio jurídico para fluxos comerciais.
O que eu escolheria de verdade (e por quê)
Depois de analisar SKUs de preço, listas de campos, discussões da comunidade e documentação das ferramentas, minha conclusão é esta:
- Use a API oficial quando você precisar de dados em tempo real, em conformidade com os termos, dentro de um app de produção, ou quando os campos Essentials/Pro forem suficientes e seu volume ficar abaixo de 10 mil/mês. As franquias gratuitas são generosas em pequena escala, e a qualidade dos dados é impecável.
- Use scraping (API gerenciada ou ferramenta sem código) quando você precisar de avaliações completas, horários de pico, Q&A, contexto competitivo ou qualquer campo que a API não expõe. Também quando seu volume ultrapassar 10 mil–100 mil registros/mês e você estiver pedindo campos ricos (Enterprise + Atmosphere) — a conta da API fica difícil de justificar.
- Use os dois quando seu fluxo exigir Place IDs canônicos e dados estruturados básicos (API) mais inteligência profunda da página visível (scraping). Isso é mais comum do que muitos artigos admitem.
O ponto de virada do custo: abaixo de cerca de 10 mil registros/mês com campos básicos, a API é mais simples e muitas vezes gratuita. Acima disso, especialmente para dados ricos, scraping passa a ser mais econômico. Em 1 milhão de registros com campos Enterprise + Atmosphere, você está olhando para cerca de US$ 18 mil/mês na API contra uma fração disso com um scraper gerenciado.
Se você quiser testar isso na prática, a Thunderbit Chrome Extension é a forma mais rápida de ver o que o scraping captura em comparação com a API. Para fluxos de desenvolvedor, a documentação da API da Thunderbit tem tudo o que você precisa para começar. E, para leituras mais profundas sobre web scraping sem código ou AI web scraping de forma geral, já cobrimos esses temas em detalhes no blog.
Principais conclusões
- A Google Places API é a ferramenta certa para apps de produção, autocomplete e consultas estruturadas de locais — mas limita avaliações a 5, fotos a 10 e não expõe horários de pico, Q&A ou sugestões de concorrentes.
- O scraping captura tudo o que está visível numa página do Google Maps, incluindo conjuntos completos de avaliações e dados de horários de pico, mas exige lidar com defesas anti-bot ou pagar por um serviço gerenciado.
- Abaixo de 10 mil registros/mês, as franquias gratuitas da API muitas vezes a tornam a opção mais barata. Acima de 100 mil, scraping ou APIs de scraping gerenciadas costumam ser mais econômicos para dados ricos.
- Scrapers DIY quebram com frequência por causa das defesas anti-bot do Google e das mudanças no DOM — reserve mais de 40 horas de desenvolvimento por ano para manutenção, ou use uma ferramenta gerenciada.
- A melhor estratégia no mundo real costuma ser híbrida: API para IDs canônicos e campos básicos, scraping para a inteligência profunda que a API não devolve.
- A Thunderbit atende aos dois lados: uma extensão Chrome para quem não quer código e uma API/servidor MCP com JSON estruturado para desenvolvedores.
FAQs
É possível obter mais de 5 avaliações do Google pela Places API?
Não. A Google Places API limita o retorno de avaliações a 5 por local, ordenadas por relevância. Isso acontece desde o lançamento da API e não mudou, apesar de anos de pedidos da comunidade de desenvolvedores. Para acessar todas as avaliações disponíveis de uma empresa, o scraping (feito por conta própria ou via API de scraping gerenciada) é a única opção.
Fazer scraping do Google Maps é legal?
Não existe uma resposta universal de sim ou não. Fazer scraping de dados publicamente visíveis do Google Maps pode violar os Termos de Serviço do Google, e a aplicação vai de bloqueio de IP até, raramente, ação legal. Muitas empresas usam scraping para pesquisa interna e inteligência competitiva sem problemas. APIs de scraping gerenciadas absorvem parte do risco de conformidade, mas não são um escudo jurídico. Se você estiver construindo um produto comercial ou processando dados pessoais, consulte um advogado.
Quanto custa a Google Places API para 100 mil consultas?
Depende dos campos solicitados. Para Place Details na faixa Essentials, cerca de US$ 450. Na faixa Pro, cerca de US$ 1.615. Em Enterprise + Atmosphere (que inclui avaliações e comodidades), cerca de US$ 2.475. Se o seu fluxo também exigir Text Search Pro para descoberta, some mais cerca de US$ 3.040. Essas estimativas usam as faixas de volume publicadas pelo Google e assumem uma requisição faturável por registro após a franquia gratuita.
Qual é a diferença entre uma API de scraping e uma ferramenta sem código para scraping?
Uma API de scraping (como a Open API da Thunderbit) é para desenvolvedores que integram scraping em código, pipelines de automação ou fluxos de agentes de IA via requisições HTTP. Já uma ferramenta sem código (como a Thunderbit Chrome Extension) permite que usuários não técnicos apontem, cliquem e exportem dados do navegador sem escrever código. Ambas podem devolver dados estruturados; a diferença está na interface e no modelo de integração.
A Thunderbit funciona em páginas do Google Maps?
Sim. A extensão Chrome pode fazer scraping dos resultados de busca do Google Maps e de perfis individuais de empresas — a IA sugere campos automaticamente, e você pode usar o modo cloud para até 50 páginas simultâneas. O endpoint POST /extract da API com renderMode: "full" lida com páginas renderizadas em JavaScript pelo Google Maps e devolve JSON estruturado compatível com schema. O servidor MCP permite que agentes de IA coletem dados do Google Maps durante o fluxo.
Saiba mais


