Dos datos valiosos de Mercado Libre que solo salen con la sesión de vendedor, y cómo extraerlos
Hay dos cosas que Mercado Libre no expone por la API pública y que solo se consiguen desde el navegador con la sesión de vendedor abierta. Las dos se extraen del estado embebido _n.ctx.r de las páginas de Seller Center (framework interno de MELI), o de una API interna que acepta la cookie de sesión.
1. Posición de la tienda en la categoría. Hay una API interna que devuelve JSON:
GET https://vendedores.mercadolibre.com.ar/metricas/benchmark/api/ranking/bricks?category_id=1403&start_period=currentMonth&from_current=&to_current=
category_id=1403 es Alimentos y Bebidas. La ruta es bricks[0].bricks[0].data con header y rows; cada fila trae posición, cambio contra el período anterior, ventas brutas, cantidad de ventas, visitas y conversión. Los nombres de los competidores vienen como alias por confidencialidad; la fila propia trae owner: true.
Al 26-ago-2026 estamos #10 de Alimentos y Bebidas, +1 puesto, $335,7M brutos, 20.668 ventas, 122.621 visitas, 16,9% de conversión — la mejor del grupo visible. Para pasar al #9 faltan $8,2M.
La lectura que importa: el que está #5 (Open 25) factura $410,2M con 228.000 visitas y 9,7% de conversión. Convertimos mucho mejor y facturamos menos: el cuello de botella es tráfico, no conversión.
CORREGIDO EL 17-SEP-2026 — LA CANTIDAD SÍ SALE POR API. Lo de abajo sigue siendo
cierto para el DETALLE por envío (id, turno, estado, capacidad asignada): eso necesita la
sesión. Pero cuántas unidades vienen se saca restando dos endpoints públicos:
total_stock de /marketplace/fbm/user-products/{up}/replenishment?country=AR
− available_quantity de /inventories/{inv}/stock/fulfillment
La doc de "Planes de reposición para fulfilment" define total_stock textualmente:
"Contempla las unidades disponibles en almacenamiento, **las unidades en espera de
arribo, las unidades reservadas en transferencia** y, cuando aplica, unidades
almacenadas que podrían estar disponibles una vez resueltas restricciones por falta de
documentación fiscal", mientras que Stock "representa únicamente las unidades disponibles
en almacenamiento Full".
Así que la resta son tres cosas juntas, no sólo lo que viaja: en espera de arribo +
reservadas en transferencia + retenidas por papeles. Por eso el tablero lo llama
"pendiente de entrar a FULL" y no "en camino".
Lo hace scripts/ml_encamino.py por launchd a las 7:15 y 15:15 (ai.plant.ml-encamino).
Al 17-sep: 15.135 unidades pendientes en 167 productos, contra 18.757 disponibles en
FULL — o sea que el 45% de lo que ML cuenta todavía no entró. El dato viejo, copiado
a mano, decía 7.530.
El error de método a no repetir: se concluyó "no hay API" después de probar ocho rutas de
inbound, sin revisar si un endpoint que YA usábamos para otra cosa traía el número por
otro lado. Lo destrabó una pregunta de Gabriel ("¿revisaste lo que está en envío a
full?") cuando habían salido 12 pallets ese mismo día.
2. Envíos a FULL (mercadería en camino). No hay API — probé ocho rutas, todas 403 o 404, y la doc lo dice explícito. La página vendedores.mercadolibre.com.ar/shipping/inbounds la trae server-rendered en _n.ctx.r.appProps.pageProps.data.results, paginada con ?page=N (20 por página).
Cuidado con el nombre de los campos, que está al revés de lo intuitivo: products_count son las unidades declaradas y units_count es la cantidad de SKUs distintos. on_sale_units son las aptas para Full. Los estados: working/scheduled es en preparación con turno reservado, received/in_progress es recibido sin terminar de procesar, closed_with_changes y closed_ok son cerrados, expired vencido.
La misma página trae segmented_seller_stock_health: capacidad asignada en FULL, ocupada y umbral de aviso. Al 26-ago: 32.628 unidades ocupadas de 373.130 asignadas — 8,7%, sobra muchísimo espacio.
Al 26-ago había 7.530 unidades en camino en dos envíos (#75330074 con 6.090 u en 147 SKUs y turno el 28/ago, y #71392527 con 1.440 u). Eso es la explicación de los $61,6M que no cuadran en FULL (ver plant-stock-sobrevaluado).
Las dos viven en KV como ml:posicion y ml:encamino, y se actualizan a mano desde
el navegador porque el Worker no tiene la cookie de sesión.
Por qué estas dos no se pueden poner en un cron, y buybox y marcasgap sí (17-sep-2026).
La cookie de sesión de ML es HttpOnly: document.cookie no la expone, así que no se
puede guardar en ~/.config/plant-cf/ y leerla desde un script, que es el patrón de
todo lo demás. La única automatización posible para estas dos es una tarea programada
que maneje el Chrome del usuario, y necesita Chrome abierto y logueado. **Ojo con la
cuenta: la de vendedor de Plant es 314922091 / PLANTMARKET**; los tres Chrome de
Gabriel al 17-sep estaban con la 190620474, y el ranking devuelve 200 con
"No tienes ventas en este periodo" en vez de un error — parece un problema de datos y
es de sesión.
En cambio ml:buybox y ml:marcasgap, que también se cargaban a mano, **no
necesitaban navegador** y ya son cron: ver ml-caja-de-compra. Mauro además baja el stock de ML a diario a una planilla propia con su mapeo MLA → producto madre (los IDs vienen de NetSuite, el sistema anterior).
Datos/ml-datos-solo-por-sesion