O usuário Antonio Rincon publicou no TabNews um artigo que deveria estar na lista de leitura obrigatória de todo desenvolvedor brasileiro que mexe com e-commerce: a VTEX, plataforma que roda lojas como Americanas, Submarino, Shoptime e milhares de outras, expõe uma API REST pública de catálogo, sem chave, sem login, sem autenticação. E quase ninguém usa.
O endpoint é simples: https://{dominio-da-loja}/api/catalog_system/pub/products/search. Um curl básico já devolve um array JSON completo com nome, preço, marca, SKUs, sellers e estoque. Nada de browser headless, nada de parser de HTML, nada de proxy. A mesma API que o front-end da loja consome todo dia está aberta para qualquer um.
O que a API devolve
A estrutura do JSON é direta: cada produto tem productId, productName, brand, linkText (usado para montar a URL canônica do produto), e um array de items[], os SKUs. Cada SKU tem seus sellers[], e dentro de cada seller está o commertialOffer (sim, com o typo histórico que a VTEX nunca corrigiu porque quebraria todas as integrações existentes).
Dentro do commertialOffer estão os campos que realmente importam: Price (preço atual com desconto), ListPrice (preço de tabela, o “de” riscado) e AvailableQuantity (estoque). Em marketplaces, o mesmo SKU pode ter vários sellers com preços diferentes. Para monitoramento simples, o primeiro seller é o padrão da loja.
Os parâmetros que fazem a diferença
A API aceita busca full-text com ft= (ex: ?ft=notebook), paginação por janela com _from e _to (máximo de 50 itens por requisição), ordenação com O= (por preço ascendente/descendente, mais vendidos, data de lançamento) e filtros estruturados com fq= (por ID do produto, categoria, marca, faixa de preço ou especificações).
Um detalhe que confunde: quando há mais resultados que a janela pedida, a VTEX responde com HTTP 206 (Partial Content): e isso não é erro, é o comportamento normal de paginação. O header resources indica o range retornado e o total disponível. Na prática, trate 200 e 206 como sucesso.
Há também um limite de 2.500 resultados por busca. Para catálogos grandes, a recomendação é segmentar por categoria, marca ou faixa de preço em vez de paginar uma busca única.
Muito além da busca: cross-selling, facets e ofertas
A API pública de catálogo não se resume à busca. A VTEX expõe também endpoints de cross-selling que permitem consultar, para um determinado produto, quais outros produtos os clientes viram, compraram juntos, ou consideram similares. Tudo via /api/catalog_system/pub/products/crossselling/. São sete endpoints: whosawalsosaw, whosawalsobought, whoboughtalsobought, showtogether, accessories, similars e suggestions.
Há também endpoints de facetas (filtros de busca por categoria), ofertas por produto e SKU, e um endpoint de autocomplete (/buscaautocomplete). Tudo público, tudo sem autenticação.
O que dá para fazer com isso (e com agentes de IA)
O caso de uso mais imediato é o monitoramento de preço de concorrentes. Preço em e-commerce muda de madrugada, muda no fim de semana. Com essa API, um script agendado pode rodar a busca a cada N horas, guardar um snapshot {productId -> preço}, e na execução seguinte comparar produto a produto, emitindo só o que variou, com delta e percentual. Sem browser, sem proxy, sem quebrar quando a loja redesenha a página.
Mas o potencial vai muito além com a integração a agentes de IA. O ecossistema MCP (Model Context Protocol) já tem pelo menos três implementações de servidores MCP para a VTEX:
- v-hansen/vtex_mcps – 43 servidores MCP independentes expondo 1.669 ferramentas que cobrem catálogo, pedidos, checkout, pagamentos, logística e mais. Cada API group da VTEX vira um pacote npm instalável com
npx. - Volve-Tech/vtex-mcp-server – 163+ endpoints com cobertura completa de catálogo, preços, inventário e promoções.
- leosepulveda/mcp-vtex – 164 ferramentas para gerenciar catálogo, inventário, preços e marketplaces via linguagem natural.
Isso significa que um agente de IA (Claude, ChatGPT, Cursor) pode, em linguagem natural, buscar produtos, consultar preços, atualizar estoque, criar categorias e gerenciar o catálogo inteiro de uma loja VTEX sem uma linha de código de integração. O desenvolvedor só precisa configurar as credenciais da loja e o agente faz o resto.
A própria VTEX lançou recentemente o VTEX Developer MCP, um servidor oficial que conecta assistentes de IA à documentação e às APIs da plataforma. É um sinal claro de que a empresa está apostando nesse ecossistema.
Para quem não quer manter o estado dos snapshots de preço, o próprio Antonio Rincon criou um Apify Actor chamado vtex-price-monitor: você informa o domínio da loja e os parâmetros de busca, agenda a recorrência, e ele devolve cada produto com currentPrice, previousPrice, delta e a flag priceChanged, em JSON, CSV ou Excel, com API e MCP.
É importante lembrar que, apesar de ser uma API pública, isso não significa que você pode sair fazendo milhões de requisições sem consequências. Qualquer empresa que se preze monitora o uso abusivo das suas URLs. Fazer scraping pesado contra a API de catálogo da VTEX pode resultar em bloqueio do seu IP, rate limiting agressivo ou até mesmo acionamento jurídico, dependendo da política de cada loja. O uso inteligente dessa API é com moderação: algumas dezenas de requisições por hora para monitorar preços de concorrentes passa despercebido; varrer o catálogo inteiro de 50 em 50 requisições o dia inteiro, não. Respeite os limites, use intervalos razoáveis entre as chamadas e, de preferência, consuma a API como um cliente normal da loja faria.
O mais impressionante é que tudo isso sempre esteve lá, documentado e aberto. A VTEX publica as especificações OpenAPI de todas as suas APIs num repositório público no GitHub. O que faltava era alguém mostrar que a porta dos fundos é, na verdade, a porta da frente.
Fontes: TabNews – Antonio Rincon, VTEX Developers – Legacy Search API, GitHub – v-hansen/vtex_mcps, VTEX Developer MCP
