Análise do Mercado Livre em 2026: por que o parser coleta preços da zona errada

Você exportou 40 mil cartões do Mercado Libre, calculou o preço médio na Argentina e entregou o relatório. O problema é que esses não são os preços da Argentina. Esses são os preços para o código postal 1430 — a zona padrão que a plataforma atribui a todos que não informaram para onde enviar.

O Mercado Libre opera em 18 países da América Latina, a receita do grupo para 2025 foi de 28,9 bilhões de dólares, e a empresa conta com 123.670 funcionários. Para a análise de e-commerce, essa é a principal fonte de dados na região e, ao mesmo tempo, a armadilha mais subestimada: a plataforma fornece preços diferentes, diferentes opções de entrega e diferentes vencedores do buy box, dependendo de onde a solicitação veio e qual zona de entrega a sessão vê. Vamos analisar o que exatamente está quebrado e como coletar corretamente.

O que mudou em 2026: API praticamente fechada

Há apenas alguns anos, "fazer parsing do Mercado Libre" era resolvido por meio da API pública: GET api.mercadolibre.com/sites/MLA/search?q=iphone retornava resultados sem necessidade de autenticação. Hoje, isso já não é mais o caso.

Verificação em 12 de setembro de 2026 a partir de um IP de servidor comum, sem token:

• /sites — HTTP 403, corpo {"code":"PA_UNAUTHORIZED_RESULT_FROM_POLICIES","blocked_by":"PolicyAgent","message":"At least one policy returned UNAUTHORIZED."}
• /sites/MLA/search?q=iphone&limit=1 — HTTP 403, {"message":"forbidden","error":"forbidden"}
• /items/{id} — HTTP 403, o mesmo PolicyAgent

Além disso, o problema não está apenas na ausência de um token. Vendedores e integradores em reclamações públicas descrevem o mesmo cenário com um token de acesso válido: /users/me e pedidos respondem normalmente, enquanto endpoints de catálogo e classificação retornam blocked_by: PolicyAgent. A política de acesso à API está sendo endurecida pontualmente, por endpoints, e a documentação não está acompanhando isso.

Paralelamente, a plataforma tem dois prazos técnicos para aqueles que ainda vivem na API oficial:

• a partir de 30 de agosto de 2026 os aplicativos devem ser separados: um aplicativo para o Mercado Libre e outro para o Mercado Pago. Isso é verificado através de GET applications/$APP_ID — se nos scopes ainda houver permissões do tipo urn:mp:..., o aplicativo precisa ser reformatado, caso contrário, perderá o acesso à API do Mercado Libre;
• o envio do token de acesso nos parâmetros de consulta foi considerado inseguro: tais solicitações a plataforma começará a rejeitar com uma resposta 301. O token deve ser enviado apenas no cabeçalho Authorization: Bearer.

A conclusão prática é simples: a API oficial em 2026 é um canal para o vendedor que está trabalhando com sua conta, e não uma ferramenta de análise de mercado. Se a tarefa é monitorar concorrentes e preços por região, você está trabalhando com a vitrine pública. O que exatamente escolher para uma tarefa específica, discutimos no material API oficial, conjunto de dados pronto ou seu próprio parser.

Sete vitrines em vez de um site

O Mercado Libre não é um único catálogo com filtro por país, mas um conjunto de plataformas independentes com seus próprios domínios, moedas e ofertas de produtos. Na API, eles são chamados de site_id:

• MLA — Argentina (mercadolibre.com.ar, ARS)
• MLB — Brasil (mercadolivre.com.br, BRL)
• MLM — México (mercadolibre.com.mx, MXN)
• MLC — Chile, MCO — Colômbia, MLU — Uruguai, MPE — Peru, MLV — Venezuela

O mesmo item em MLA e MLB é na verdade dois cartões diferentes, dois vendedores diferentes, dois esquemas logísticos diferentes. Compará-los "de frente" não faz sentido: é necessária uma normalização pela moeda e pelas condições de entrega. A propósito, sobre a moeda — a plataforma fornece as regras de formatação em HTML: para a Argentina, isso é "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". Parsers que cortam o preço com expressões regulares usando ponto cometem erros mil vezes nas vitrines latino-americanas.

O principal: preço e entrega são calculados a partir da zona do destinatário

Aqui está um fragmento que está embutido diretamente no HTML da página de resultados listado.mercadolibre.com.ar quando a solicitação é feita sem endereço:

"location_info":{"zipcode":"1430","inferred_zipcode":false,"default_zipcode":true,"user_zone":"X19"}

Isso se lê assim: o índice 1430, ele não foi derivado do seu IP (inferred_zipcode: false), ele é padrão (default_zipcode: true). No cabeçalho, está escrito "Enviar a Capital Federal" — ou seja, a plataforma decidiu em silêncio que você está na área metropolitana de Buenos Aires e, a partir daí, calcula tudo exatamente para ela.

E ela calcula muita coisa. No mesmo HTML estão os banners de entrega, vinculados à zona: same_day_free_shipping com o texto "Llega gratis hoy", ícone vpp_full_icon — "Enviado por FULL" (produto do armazém da plataforma). Em uma única página de resultados para a solicitação "iphone", houve 96 menções de entrega gratuita. A zona também determina o bloco buy_box com "Outra opção de compra": qual vendedor ganhará o cartão é determinado, entre outras coisas, por quem entrega mais barato e mais rápido para um índice específico.

Resultado: um parser que nunca definiu a zona de entrega coleta não "o mercado da Argentina", mas uma amostra de uma única cidade. Para um relatório sobre o país com cidades de um milhão de habitantes a mil quilômetros da capital, isso é um erro que não se manifesta de forma alguma — os números parecem plausíveis, mas simplesmente não respondem à pergunta certa.

Barreira na entrada: /gz/account-verification

Uma segunda surpresa aguarda no nível de transporte. A solicitação para listado.mercadolibre.com.ar/iphone não retorna resultados imediatamente: vem um HTTP 302 para /gz/account-verification?go=...&tid=... — sua própria página de verificação de dispositivo. Isso não é Cloudflare e não é DataDome: no código da barreira não há reCAPTCHA, Turnstile ou marcadores de anti-bots de terceiros, mas sim uma dezena de chamadas à mecânica do dispositivo. A página pesa cerca de 41 KB, é construída em JavaScript e sem ele não mostra nada.

O comportamento durante a verificação se mostrou revelador. A primeira solicitação de um IP de servidor limpo passou pela barreira: veio um resultado real de 2.425.906 bytes — 50 blocos ui-search-layout e 120 nós de preço andes-money-amount__fraction, tudo renderizado no servidor. Solicitações repetidas do mesmo endereço já esbarraram em /gz/account-verification e não passaram adiante. As vitrines brasileira e mexicana a partir do mesmo IP não permitiram acesso algum.

Essa é uma mecânica típica de "reputação": o endereço recebe um pequeno crédito de confiança, o gasta em algumas solicitações e se fecha. Nenhum teste isolado aqui prova nada — o importante é que não há acesso sustentável a partir do pool de data centers, e o comportamento varia de país para país.

Outro detalhe dos cabeçalhos de resposta: a plataforma define _d2id (identificador do dispositivo com validade de um ano, que também é duplicado em x-request-device-id) e _mldataSessionId com Max-Age=1800. Trinta minutos — essa é a duração natural da sessão, que deve ser considerada para a retenção do IP.

O que diz o robots.txt

Antes de começar a coleta, é bom ler as regras da plataforma. No robots.txt de ambas as vitrines (argentina e brasileira), o bloco superior é idêntico e bastante claro:

• proibição total (Disallow: /) para crawlers de IA: Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User;
• permitido para bots de pré-visualização de redes sociais: FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot;
• para Bingbot — Crawl-delay: 5 e uma longa lista de seções fechadas: /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ e outras.

Isso leva a duas conclusões práticas. A primeira: o carrinho, o checkout e os perfis de usuários estão claramente fechados — não é necessário acessar esses dados nem técnica nem legalmente. A segunda: Crawl-delay: 5 para o bot de busca é um guia honesto sobre o ritmo que a plataforma espera da automação. Cinco segundos por solicitação de um único endereço é um ponto de partida razoável, e não um número aleatório.

Como coletar corretamente: ordem das ações

1. Fixe a matriz de coleta. Não "Mercado Libre", mas uma lista de pares "país × zona de entrega". Para a Argentina, isso é, por exemplo, Capital Federal, Córdoba, Rosario, Mendoza; para o Brasil — São Paulo, Rio, Belo Horizonte, Recife. O preço sem a indicação da zona não faz sentido, e essa decisão deve ser tomada antes da primeira linha de código.
2. Obtenha um IP residencial do país necessário. Endereços de servidor nas vitrines brasileira e mexicana não passaram pela barreira de forma alguma, na argentina se esgotaram após a primeira solicitação. Um endereço residencial local resolve tanto a questão de acesso quanto a questão de confiabilidade: a plataforma inicialmente mostra a você o mesmo que mostraria a um comprador local.
3. Mantenha o IP durante toda a sessão. O cookie de sessão dura 30 minutos — a rotação a cada solicitação redefine tanto ele quanto a zona escolhida, e você novamente recebe o índice padrão. Uma sessão fixa de 10 a 30 minutos para uma zona, depois muda. Como escolher a duração da janela, discutimos no guia sobre sessões fixas.
4. Use um motor de navegador, e não um cliente HTTP simples. A página /gz/account-verification é totalmente construída em JavaScript: sem a execução de scripts, você ficará preso na barreira. Use Playwright ou um similar que mantenha o estado entre os passos.
5. Defina explicitamente a zona de entrega. O link leva a /addresses/v3/navigation/hub; após a definição do endereço, o estado é mantido em cookie de sessão. Execute esse procedimento uma vez por sessão, e não para cada cartão.
6. Faça do location_info um checksum. Em cada página salva, verifique se o zipcode corresponde ao alvo e se default_zipcode se tornou false. Se a flag permanecer true — não escreva a linha na vitrine de dados, ela foi coletada para a zona errada. Apenas essa verificação elimina a maior parte dos erros silenciosos.
7. Recupere preços do HTML do servidor. O preço e os banners de entrega já estão renderizados no servidor — não é necessário perseguir endpoints JSON internos. Armazene junto ao preço o próprio zipcode, user_zone, currency_id e um timestamp: sem eles, o número não pode ser verificado.
8. Mantenha o ritmo. A orientação da própria plataforma é de cinco segundos entre solicitações de um único endereço. Se precisar de velocidade — amplie o pool de endereços, e não a frequência de um único IP: é o pico de solicitações de um único endereço que fecha a barreira.

Armadilhas que serão descobertas tarde demais

Erro silencioso da zona padrão. O erro mais caro não aparece com uma exceção. Os dados são coletados, o relatório é construído, a decisão sobre a formação de preços é tomada — e apenas após um trimestre se descobre que toda a análise do Brasil descreve um único bairro de São Paulo.

Peso das páginas. Uma página de resultados — 2,4 MB. Mil páginas por dia em quatro países e quatro zonas — isso gera dezenas de gigabytes de tráfego por mês. Em um plano residencial com pagamento por gigabyte, isso é uma despesa significativa, portanto, vale a pena desativar imediatamente o carregamento de imagens e fontes no motor do navegador: os preços estão no HTML, as imagens para o parser são um desperdício puro.

Comparação de países sem normalização. ARS, BRL, MXN e diferentes separadores de milhares. Normalize para uma única moeda com a taxa do dia da coleta e armazene o preço original e a moeda separadamente, caso contrário, recalcular retroativamente não será possível.

Aposta na API oficial. Se a integração ainda estiver na API, mantenha em mente a exigência de aplicativos separados a partir de 30 de agosto de 2026 e a mudança do token de consulta para o cabeçalho. A perda silenciosa de acesso à API parece exatamente como um bug no seu código.

Quais proxies são necessários para essa tarefa

Residenciais — uma opção viável para coletar preços e entregas. É necessário um endereço exatamente do país cuja vitrine você está acessando, e preferencialmente da região cuja zona de entrega você está verificando: assim, os dados são obtidos e permanecem confiáveis. Proxies residenciais com retenção de sessão atendem a ambos os requisitos ao mesmo tempo.

Móveis — onde a barreira é especialmente teimosa. A América Latina é uma região com uma alta proporção de tráfego móvel, e um endereço de operadora celular parece para a plataforma o mais comum possível. Justificáveis em cortes estreitos, mas críticos, e não em grandes exportações.

Proxies de data center — para exploração e tarefas administrativas: ler robots.txt, capturar a estrutura da página, verificar a disponibilidade do domínio. Para coleta regular de preços, como mostrou a verificação, o recurso não é suficiente.

Resumindo

O Mercado Libre em 2026 não fornece dados de forma anônima. A API oficial foi fechada por políticas do PolicyAgent, a vitrine encontra você com sua própria verificação de dispositivo, e o principal número — preço com entrega — é calculado a partir da zona do destinatário, que a plataforma atribui por padrão, caso não seja especificada. Um parser correto aqui se diferencia do incorreto não pela astúcia de contornar, mas pela disciplina: país, zona, moeda e location_info ao lado de cada linha. Todo o resto é uma questão de onde suas solicitações estão vindo.