Como monitorar preços, estoque e sellers no Mercado Livre com API

Monitorar o Mercado Livre de forma manual funciona por pouco tempo.

Uma planilha com 30 URLs, alguns prints e uma rotina semanal pode ser suficiente para uma categoria pequena. Mas quando o time precisa acompanhar centenas ou milhares de produtos, vendedores e variações de preço, o processo vira uma operação de dados.

O objetivo deixa de ser “olhar um anúncio” e passa a ser responder perguntas como:

quais sellers reduziram preço nas últimas 24 horas?
qual produto ficou sem estoque?
qual seller novo entrou em uma categoria?
a menor oferta vem de loja oficial, seller terceiro ou revendedor?
o preço mudou mesmo ou foi o frete que mudou a competitividade?
quais anúncios aparecem com mais frequência para uma busca importante?

Este guia mostra como montar um fluxo de monitoramento de preços no Mercado Livre com API, usando dados públicos estruturados em JSON, sem manter crawler próprio.

Antes de tudo: esta não é a API oficial do Mercado Livre

Existe uma diferença importante entre dois tipos de API.

A API oficial do Mercado Livre é indicada para operações de vendedor, como gerenciar os seus próprios anúncios, pedidos, autenticação, integrações de loja e rotinas ligadas a uma conta autorizada.

A GeckoAPI atende outro trabalho: coletar e estruturar dados públicos para inteligência de mercado, BI, pricing, catálogo, monitoramento de concorrentes e automações internas.

Use a API oficial quando você precisa operar a sua própria loja.

Use uma API de dados públicos quando você precisa observar o mercado: produtos, preços, disponibilidade, sellers, listagens e sinais competitivos.

Essa distinção importa porque muita gente pesquisa por api mercado livre querendo integração de seller. Se o seu caso é monitoramento competitivo, o caminho técnico é outro.

O que dá para monitorar

Em um pipeline de inteligência de marketplace, os campos mais úteis normalmente são:

título e URL do produto;
preço atual;
preço regular ou preço de referência, quando disponível;
disponibilidade;
quantidade em estoque, quando exposta publicamente;
seller principal;
outros sellers associados ao produto;
reputação e nível do seller;
frete grátis ou sinais de envio;
avaliações e volume de reviews;
posição do produto em uma busca ou listagem;
categoria, marca e atributos do produto.

Esses dados podem alimentar dashboards de BI, alertas de preço, modelos de elasticidade, rotinas de catálogo, listas de sellers, agentes de IA e relatórios para clientes.

O modelo certo: PLP para descobrir, PDP para aprofundar

Um erro comum em monitoramento de marketplace é começar com uma lista fixa de URLs de produto e consultar apenas essas páginas todos os dias.

Isso ajuda, mas deixa buracos.

Em marketplaces, o concorrente real pode mudar de URL, um seller novo pode aparecer em outra listagem, um produto equivalente pode ganhar visibilidade e a oferta mais competitiva pode não estar no mesmo anúncio que você salvou na planilha.

Por isso, o fluxo mais confiável combina dois tipos de extração:

Etapa	O que faz	Quando usar
PLP	Extrai resultados de busca ou listagem	Para descobrir produtos, sellers, preços e posições por keyword ou URL
PDP	Extrai a página de detalhe do produto	Para aprofundar preço, estoque, seller, atributos, avaliações e outros sellers

Pense em PLP como radar e PDP como ficha técnica.

A PLP responde:

O que aparece no mercado para esta busca?

A PDP responde:

O que está acontecendo neste produto específico?

Para um monitoramento sério de Mercado Livre, você normalmente usa os dois.

Exemplo 1: buscar produtos por keyword com PLP

Para descobrir ofertas a partir de uma busca, use o endpoint de extração com target: "mercadolivre.com.br" e type: "plp".

curl -X POST "https://api.geckoapi.com.br/v1/extract" \
  -H "Authorization: Bearer SUA_CHAVE" \
  -H "Content-Type: application/json" \
  -d '{
    "target": "mercadolivre.com.br",
    "type": "plp",
    "keyword": "notebook gamer",
    "page": 1
  }'

Você também pode usar uma URL de listagem:

curl -X POST "https://api.geckoapi.com.br/v1/extract" \
  -H "Authorization: Bearer SUA_CHAVE" \
  -H "Content-Type: application/json" \
  -d '{
    "target": "mercadolivre.com.br",
    "type": "plp",
    "url": "https://lista.mercadolivre.com.br/notebook-gamer",
    "page": 1
  }'

A resposta de PLP retorna uma lista de itens. Um exemplo simplificado:

{
  "executionId": "exec_123",
  "data": {
    "items": [
      {
        "name": "Notebook Gamer 16GB SSD 512GB",
        "url": "https://produto.mercadolivre.com.br/MLB-1234567890-produto-exemplo-_JM",
        "price": 4299.9,
        "currency": "BRL",
        "sellerId": "123456789",
        "sellerName": "Tech Store Oficial",
        "sellerCity": "Sao Paulo",
        "sellerState": "SP"
      }
    ],
    "totalResults": 1280,
    "nextPage": 2
  }
}

Documentação técnica: Mercado Livre PLP.

Exemplo 2: enriquecer uma URL com PDP

Depois de descobrir produtos relevantes pela PLP, você escolhe as URLs que merecem aprofundamento e consulta a PDP.

curl -X POST "https://api.geckoapi.com.br/v1/extract" \
  -H "Authorization: Bearer SUA_CHAVE" \
  -H "Content-Type: application/json" \
  -d '{
    "target": "mercadolivre.com.br",
    "type": "pdp",
    "url": "https://produto.mercadolivre.com.br/MLB-1234567890-produto-exemplo-_JM"
  }'

Um payload de PDP pode trazer campos como:

{
  "executionId": "exec_456",
  "data": {
    "name": "Notebook Gamer 16GB SSD 512GB",
    "price": 4299.9,
    "availability": "InStock",
    "stockQuantity": 7,
    "sellerName": "Tech Store Oficial",
    "sellerId": "123456789",
    "sellerLevel": "5_green",
    "sellerType": "brand",
    "aggregateRating": 4.8,
    "reviewCount": 312,
    "otherSellers": [
      {
        "sellerName": "Loja Parceira",
        "sellerId": "987654321",
        "price": 4399.9,
        "sellerUrl": "https://lista.mercadolivre.com.br/?seller_id=987654321"
      }
    ]
  }
}

Documentação técnica: Mercado Livre PDP.

Arquitetura recomendada para monitoramento

Um pipeline simples de monitoramento de preços pode seguir esta ordem:

Definir categorias, marcas, keywords ou SKUs monitorados.
Rodar PLP para descobrir os produtos e sellers presentes em cada busca.
Normalizar resultados por URL, título, seller e atributos importantes.
Selecionar os itens relevantes para enriquecimento.
Rodar PDP nas URLs priorizadas.
Salvar snapshots históricos com timestamp.
Comparar o snapshot atual com o anterior.
Gerar alertas, dashboards ou tarefas operacionais.

Em texto, o fluxo fica assim:

keywords e categorias
  -> Mercado Livre PLP
  -> deduplicação e priorização
  -> Mercado Livre PDP
  -> snapshots históricos
  -> alertas de preço, estoque e seller

Esse desenho evita dois extremos ruins:

consultar PDP demais e gastar crédito com produto irrelevante;
consultar apenas PLP e tomar decisão com dados superficiais.

Quais dados salvar no histórico

Se você salva apenas price, seu monitoramento fica cego.

Preço sem contexto não explica o que aconteceu. O ideal é guardar um snapshot imutável com os campos que ajudam a interpretar a mudança.

Campo	Por que salvar
`source`	Permite comparar Mercado Livre com outras fontes
`keyword` ou `category`	Mostra de qual busca o item veio
`url`	Mantém rastreabilidade do anúncio
`name`	Ajuda auditoria humana e matching
`sellerName` e `sellerId`	Separa loja oficial, seller terceiro e novos entrantes
`price`	Base do histórico de preço
`availability`	Evita tratar ruptura como aumento ou queda de preço
`stockQuantity`	Ajuda a detectar risco de ruptura
`otherSellers`	Mostra a pressão competitiva dentro da PDP
`aggregateRating` e `reviewCount`	Ajuda a comparar ofertas com confiança diferente
`extractedAt`	Permite série histórica, variação e alertas

Na prática, trate cada coleta como uma linha nova. Não atualize o registro anterior. Insira um novo snapshot e calcule variações depois.

Alertas que geram ação

Monitoramento de preço só cria valor quando vira decisão.

Alguns alertas úteis:

queda abaixo do piso: concorrente rompeu um limite definido pelo time de pricing;
novo menor preço: uma oferta ficou mais agressiva que o benchmark anterior;
mudança de seller vencedor: o menor preço saiu de um seller e passou para outro;
produto indisponível: concorrente perdeu estoque e abriu oportunidade comercial;
entrada de novo seller: um vendedor novo começou a competir na categoria;
mudança de sortimento: produtos novos aparecem com frequência em uma busca;
aumento de reviews: um item concorrente ganhou tração;
variação por faixa de preço: a categoria ficou mais barata ou mais cara em bloco.

Esses alertas podem ir para Slack, email, planilha, BI, CRM ou para um workflow interno.

Como usar isso em BI

Para BI, o caminho mais simples é salvar snapshots em uma tabela com colunas padronizadas.

Um modelo inicial:

marketplace
keyword
url
product_name
seller_id
seller_name
price
availability
stock_quantity
rating
review_count
extracted_at

Com isso, você consegue criar visões como:

menor preço por keyword;
sellers mais frequentes por categoria;
variação diária por produto;
ruptura por concorrente;
distribuição de preço por faixa;
entrada e saída de sellers;
produtos que mais ganharam review.

Se o time já usa BigQuery, PostgreSQL, Supabase, Metabase, Power BI ou Looker Studio, a API vira uma camada de coleta. O histórico e a análise ficam no seu stack.

Quando usar apenas PLP

Use apenas PLP quando o objetivo é descobrir o mercado em escala.

Exemplos:

mapear os 50 primeiros resultados de uma categoria;
descobrir sellers que aparecem para uma keyword;
comparar faixa de preço em buscas diferentes;
identificar produtos novos;
montar uma lista inicial para prospecção ou análise.

PLP é mais eficiente quando você ainda está decidindo o que merece aprofundamento.

Quando adicionar PDP

Adicione PDP quando o produto importa o bastante para receber uma ficha completa.

Exemplos:

acompanhar um SKU estratégico todos os dias;
validar disponibilidade e estoque;
checar seller principal e outros sellers;
enriquecer atributos técnicos;
auditar uma queda de preço;
alimentar um dashboard executivo.

PDP custa mais atenção no desenho do pipeline, mas entrega o contexto que PLP nem sempre traz.

Comparando API pronta com scraper próprio

Você pode construir um scraper interno para Mercado Livre. O problema é que, em produção, scraping raramente é apenas parser HTML.

O time passa a cuidar de:

bloqueios e retentativas;
mudanças de layout;
filas e concorrência;
proxies;
observabilidade;
validação de dados;
normalização de campos;
histórico de falhas;
custo de manutenção.

Uma API pronta troca essa manutenção por um contrato mais simples: você envia target, type e os parâmetros da coleta; recebe JSON padronizado.

Se o seu diferencial não é manter crawler, faz sentido comprar essa camada e concentrar energia no produto, no BI ou na decisão comercial.

Para uma visão mais ampla de pipeline multi-marketplace, veja também: Monitoramento de preços de concorrentes com API, PLP e PDP.

Boas práticas

Antes de colocar o monitoramento em produção:

comece por poucas keywords importantes;
defina a frequência de coleta por caso de uso;
salve snapshots com timestamp;
crie deduplicação por URL, seller e título;
monitore erros e respostas vazias;
use cache quando o dado não precisa ser atualizado em tempo real;
separe ambiente de teste e produção;
documente quais campos o time de BI realmente usa.

Também vale definir limites claros: nem todo produto precisa de PDP diária. Em muitos casos, PLP diária e PDP apenas nos itens prioritários entregam um bom equilíbrio entre cobertura e custo.

Como começar com a GeckoAPI

O caminho mínimo é:

Criar uma conta no dashboard da GeckoAPI.
Gerar uma chave de API.
Testar uma chamada PLP para a keyword principal.
Escolher algumas URLs retornadas.
Rodar PDP nessas URLs.
Salvar os resultados em uma tabela.
Criar o primeiro alerta de mudança de preço ou seller.

Você pode começar pela documentação:

Com 100 créditos grátis, já dá para validar o fluxo básico, entender o payload e decidir quais buscas ou produtos merecem monitoramento contínuo.