Se você está fazendo parsing do Wildberries, Ozon ou qualquer outro site através do carregamento de páginas HTML completas, você está pagando por tráfego de proxy de 5 a 10 vezes mais do que poderia. Cada página de produto contém de 200 a 800 KB de marcação, scripts e estilos, dos quais você precisa literalmente de alguns campos: preço, disponibilidade, classificação. Neste artigo, analisamos como encontrar a API oculta do site e obter os mesmos dados diretamente, em formato JSON compacto.
Por que o parsing de HTML consome tráfego de proxy
Quando o parser carrega uma página através de uma requisição HTTP comum ou através de um navegador headless (Selenium, Puppeteer, Playwright), o servidor entrega um documento HTML completo: marcação, scripts inline, estilos, às vezes imagens em base64 e centenas de linhas de JSON com dados para widgets publicitários que você não precisa. A média de uma página de produto no Wildberries pesa entre 300 e 600 KB, enquanto no Ozon pode chegar a 800 KB, se contarmos todos os recursos relacionados (CSS, fontes, rastreadores).
Se você monitora 10.000 produtos uma vez por dia através de 3 sessões de proxy, isso facilmente se transforma em dezenas de gigabytes de tráfego por mês. Proxies residenciais e móveis geralmente são vendidos por tráfego, portanto, cada megabyte extra significa custos diretos. Enquanto isso, os dados reais que você precisa — preço, desconto, estoque, classificação — ocupam de 1 a 5 KB na resposta JSON. A diferença é de 100 a 200 vezes em volume por produto, e considerando os custos adicionais de renderização do navegador, a economia em tempo e CPU é ainda maior.
Um problema adicional do parsing HTML é a fragilidade. Sites de marketplaces frequentemente mudam a estrutura, classes CSS e a estrutura DOM. Cada uma dessas mudanças quebra o parser, que é construído com XPath ou seletores CSS. A API interna muda muito menos frequentemente, pois depende do funcionamento do aplicativo móvel e do frontend do site ao mesmo tempo.
O que é uma API oculta e de onde ela vem
Quase todo site moderno é um SPA (Single Page Application) ou um aplicativo híbrido, onde o navegador primeiro carrega o "esqueleto" da página e depois, através do JavaScript, faz requisições adicionais à API interna para obter dados reais: preços, estoques, avaliações, recomendações. Essas requisições são chamadas de APIs ocultas ou internas — elas não são documentadas publicamente, mas estão completamente abertas no tráfego do navegador.
Tecnicamente, isso geralmente são endpoints REST ou GraphQL, que retornam dados em formato JSON. Por exemplo, no Wildberries, a página do produto é carregada através de requisições do tipo card.wb.ru e wbx-content-v2.wbstatic.net, enquanto os preços e estoques vêm de uma requisição separada para basket-01.wb.ru e domínios semelhantes. No Ozon, a lógica é semelhante: o frontend acessa a API interna do composer, que agrega dados de microserviços.
É importante entender: o uso de tal API não é formalmente considerado uma invasão — você está apenas repetindo as mesmas requisições que um navegador comum do usuário faz. Mas os sites protegem esses endpoints através de sistemas anti-bot, portanto, é necessário simular cuidadosamente o comportamento de um cliente real, incluindo o uso de proxies de qualidade.
Como encontrar uma API oculta através do DevTools
Encontrar a API interna pode ser feito sem uma única linha de código, utilizando as ferramentas integradas do navegador Chrome ou Firefox. Aqui está um algoritmo passo a passo:
- Abra a página do produto desejada no Chrome, pressione F12 e vá para a aba Network.
- No filtro de requisições, selecione o tipo Fetch/XHR — assim você eliminará o carregamento de imagens, fontes e estáticos.
- Atualize a página (F5) e observe a lista de requisições que apareceram após o carregamento do esqueleto da página.
- Encontre a requisição cuja resposta (aba Response) mostra o preço do produto, nome ou outros campos necessários em formato JSON.
- Clique nessa requisição e copie-a como cURL (botão direito → Copiar → Copiar como cURL) — isso lhe dará um conjunto completo de cabeçalhos, cookies e parâmetros.
- Verifique quais parâmetros na URL são obrigatórios (código do produto, região, versão da API) e quais podem ser removidos sem perda de dados.
Depois disso, basta repetir essa requisição através de uma biblioteca HTTP comum, substituindo o código ou ID do produto, em vez de renderizar toda a página. Isso funciona para a maioria dos marketplaces — Wildberries, Ozon, Avito, assim como para muitos sites estrangeiros como Amazon e eBay.
Comparação de tráfego: HTML vs JSON API
A diferença no volume de dados é tão grande que vale a pena mostrá-la em números. Abaixo estão as medições médias para uma página de produto em marketplaces populares.
| Método de parsing | Tamanho médio da resposta | Tempo de carregamento | Renderização de JS necessária |
|---|---|---|---|
| HTML completo via Selenium | 400-800 KB | 1.5-4 seg | Sim |
| Requisição HTTP simples (requests) | 150-300 KB | 0.3-0.8 seg | Não |
| API JSON oculta | 3-15 KB | 0.1-0.3 seg | Não |
Ao monitorar 50.000 produtos por dia, a transição de um navegador headless para requisições diretas à API reduz o tráfego de aproximadamente 30-40 GB para 300-700 MB por mês. Isso não apenas economiza no tráfego de proxies, mas também reduz a carga na infraestrutura do servidor do parser — menos CPU para renderização, menos memória, mais rápida coleta de dados.
Exemplo prático em Python
Vamos considerar um exemplo simplificado: obter o preço e o estoque do produto através de uma requisição direta à API interna em vez de carregar a página completa. Este é um modelo educacional — os endpoints e parâmetros exatos devem ser determinados através do DevTools para um site específico, pois a estrutura das requisições pode variar dependendo da região e da versão da API.
import requests
def get_product_data(product_id: str, proxies: dict = None) -> dict:
"""
Obtém dados do produto através da API interna em vez de HTML completo.
proxies — dicionário com proxies no formato requests: {"http": "...", "https": "..."}
"""
url = f"https://card.example-marketplace.ru/v2/detail"
params = {
"nm": product_id,
"dest": "-1257786", # região, determinada através do DevTools
"spp": "0"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0 Safari/537.36",
"Accept": "application/json",
"Referer": f"https://www.example-marketplace.ru/catalog/{product_id}/detail.aspx"
}
response = requests.get(
url,
params=params,
headers=headers,
proxies=proxies,
timeout=10
)
response.raise_for_status()
data = response.json()
product = data["products"][0]
return {
"id": product["id"],
"name": product["name"],
"price": product["salePriceU"] / 100,
"stock": product.get("totalQuantity", 0),
"rating": product.get("reviewRating", None)
}
if __name__ == "__main__":
proxy = {
"http": "http://user:pass@proxy-host:port",
"https": "http://user:pass@proxy-host:port"
}
result = get_product_data("123456789", proxies=proxy)
print(result)
Preste atenção em três pontos neste exemplo. Primeiro, especificamos o cabeçalho Referer, porque muitas APIs verificam se a requisição veio "do navegador", e não diretamente pela URL. Em segundo lugar, usamos um User-Agent realista, e não o padrão da biblioteca requests, que é facilmente detectável. Em terceiro lugar, toda a requisição é feita em uma única chamada HTTP sem renderização — isso proporciona um ganho significativo em tráfego e velocidade.
Para endpoints GraphQL, a lógica é semelhante, mas em vez de parâmetros GET, você envia uma requisição POST com um corpo de requisição em formato JSON, onde lista explicitamente os campos necessários — isso reduz ainda mais o volume da resposta, pois o servidor retorna apenas os dados solicitados.
Trabalhando com proxies em requisições à API
Mesmo ao migrar para um formato JSON compacto, você ainda precisa de proxies — marketplaces limitam o número de requisições de um único IP e bloqueiam em caso de atividade anômala. A escolha correta do tipo de proxy aqui impacta diretamente a estabilidade do parser.
Para contornar massivamente APIs de marketplaces como Wildberries ou Ozon, proxies de data center são uma boa opção — eles oferecem alta velocidade e baixo custo de tráfego, o que é crítico em requisições frequentes a endpoints JSON leves. Mas se uma API específica estiver protegida por um anti-bot mais rigoroso e bloquear sub-redes de data center inteiras, é mais sensato mudar para proxies residenciais — eles usam endereços IP reais de usuários domésticos e têm menos chances de serem bloqueados por sub-rede.
Para APIs que dependem de aplicativos móveis (algumas versões de endpoints do Avito ou marketplaces fornecem dados apenas por tráfego móvel), pode ser necessário conectar-se através de proxies móveis — eles simulam o tráfego de operadores de telefonia móvel reais e passam por verificações que bloqueiam IPs comuns.
Ao configurar proxies no parser, é importante também espaçar as requisições no tempo e usar rotação de IP — mesmo uma requisição JSON compacta, repetida 1000 vezes em um minuto de um único endereço, levantará suspeitas no sistema de proteção. Configure um pool de várias sessões de proxy e distribua a carga entre elas, adicionando atrasos aleatórios de 1 a 3 segundos entre as requisições.
Armadilhas: tokens, assinaturas, anti-bot
APIs ocultas nem sempre estão abertas. Alguns sites protegem seus endpoints com mecanismos adicionais que precisam ser considerados ao construir o parser.
- Tokens de sessão temporários — algumas APIs exigem uma requisição prévia para obter um token, que é então passado no cabeçalho das requisições seguintes e tem um tempo de vida limitado (geralmente 5-30 minutos).
- Assinatura da requisição (signature) — os parâmetros da requisição são hashados no cliente com uma chave secreta do código JS da página. Essa assinatura precisa ser reproduzida manualmente, analisando o algoritmo, ou executada através de um navegador headless apenas na etapa de obtenção do token, e depois enviar requisições leves diretamente.
- Rate limiting por IP e por User-Agent — ao exceder a frequência de requisições, o site bloqueia temporariamente o acesso. Isso é resolvido com rotação de proxies e atrasos razoáveis.
- Fingerprinting de cabeçalhos — alguns sistemas verificam o conjunto completo de cabeçalhos (ordem, presença de Accept-Language, Sec-Fetch-*) e bloqueiam requisições com um conjunto "incompleto", característico de scripts, e não de navegadores.
- Dependência geográfica dos dados — preços e estoques em marketplaces podem variar por regiões, portanto, é importante passar o parâmetro correto de região/estoque na requisição, caso contrário, os dados serão irrelevantes.
Se a API estiver fechada com uma assinatura de requisição que é difícil de reproduzir, uma opção de compromisso é usar um navegador headless (Playwright, Puppeteer) apenas para interceptar requisições de rede e extrair a resposta JSON pronta, sem fazer parsing do DOM. Isso é mais lento que uma requisição HTTP direta, mas ainda assim mais rápido e leve do que um parsing completo da estrutura da página.
Checklist antes de iniciar o parser na API oculta
- Endpoint encontrado através do DevTools, copiado como cURL e testado no Postman ou através de requests.
- Parâmetros obrigatórios da requisição (ID do produto, região, versão da API) definidos e parâmetros excessivos excluídos.
- Cabeçalhos User-Agent, Referer e Accept-Language configurados de forma realista.
- Verificado se um token de sessão ou assinatura da requisição é necessário e pensado em como obtê-los.
- Rotação de proxies e atrasos aleatórios entre requisições configurados.
- Tipo de proxy adequado escolhido para a proteção específica do site — data center, residencial ou móvel.
- Tratamento de erros 429 e 403 adicionado com troca automática para outro proxy.
- Registro do volume de tráfego configurado para controle da economia real.
Conclusão
A transição do parsing de HTML completo para trabalhar com a API oculta não é apenas uma otimização técnica, mas uma redução direta nos custos com tráfego de proxy e infraestrutura. Em vez de carregar centenas de kilobytes de marcação desnecessária, você obtém um JSON compacto com exatamente os campos necessários para monitorar preços, estoques ou classificações. Um bônus adicional é a resistência do parser a mudanças na estrutura do site, já que APIs internas mudam menos frequentemente que o frontend.
Ao mesmo tempo, a própria metodologia de busca por APIs não elimina a necessidade de proxies de qualidade — sistemas anti-bot de marketplaces monitoram atentamente tanto requisições HTML quanto acessos a endpoints JSON. Se você está monitorando Wildberries ou Ozon em grandes volumes, comece com proxies de data center rápidos para reduzir custos e, ao primeiro sinal de bloqueios, mude para pools de IPs residenciais ou móveis para um funcionamento mais estável do parser.