Integrar tu sistema con la API de Mercado Libre: stock, precios y pedidos

Conectar tu sistema con Mercado Libre deja de ser opcional cuando el alta manual de ventas y el ajuste de stock te comen horas todos los días. Integrar tu sistema con la API de Mercado Libre se hace en cuatro pasos: crear una aplicación para obtener credenciales OAuth 2.0, autorizar la cuenta del vendedor para conseguir un access_token, suscribirte a los webhooks de pedidos (topic orders_v2) para reaccionar a cada venta en segundos, y usar los endpoints de items para empujar stock y precios desde tu ERP. El resto de esta guía es cómo armar eso sin romperte la reputación en el camino.

Por qué integrar contra la API y no seguir a mano

Cargar pedidos manualmente en tu sistema funciona hasta los 15-20 pedidos diarios. Después aparecen los tres problemas de siempre: sobreventa (vendés una unidad que ya no tenés), demoras (el pedido entra a tu logística horas tarde) y errores de tipeo en cantidades o precios. En Mercado Libre, cancelar una venta por falta de stock golpea directo tu reputación, y pasar de medalla verde a amarilla puede tirar las ventas 20-40% durante semanas.

Una integración por API resuelve esto cerrando el círculo: la venta entra sola a tu sistema, el stock se descuenta en el momento, y los demás canales se enteran enseguida. Es el mismo tipo de automatización con IA que aplicamos a cualquier flujo repetitivo, solo que acá el motor es la API oficial de ML.

Paso 1: credenciales y OAuth 2.0

Todo arranca en developers.mercadolibre.com.ar. Creás una aplicación y obtenés:

• Client ID y Client Secret — identifican tu app.
• Redirect URI — la URL a la que ML devuelve al usuario tras autorizar.
• Topics de notificación — qué eventos querés recibir (orders_v2, items, questions, claims).

El flujo es OAuth 2.0 estándar (authorization code):

1. Redirigís al vendedor a la URL de autorización de ML.
2. El vendedor acepta y ML lo devuelve a tu Redirect URI con un code.
3. Tu backend cambia ese code por un access_token (válido 6 horas) y un refresh_token.
4. Antes de que expire, usás el refresh_token para renovar sin molestar al usuario.

El error más común acá es no manejar bien la renovación: si tu token se vence a las 3 de la mañana y nadie lo renueva, te perdés ventas hasta que alguien lo note. La renovación tiene que ser automática y monitoreada. Si no querés construir esta plomería desde cero, es exactamente el tipo de trabajo de desarrollo de APIs e integraciones que conviene delegar.

Paso 2: los endpoints que vas a usar

La API REST de Mercado Libre es amplia, pero para stock, precios y pedidos te concentrás en pocos endpoints:

Acción	Método y endpoint	Notas
Ver una publicación	GET /items/{item_id}	Trae precio, stock, estado, variantes
Actualizar stock	PUT /items/{item_id} con available_quantity	En segundos impacta la publicación
Actualizar precio	PUT /items/{item_id} con price	Respetá el rate limit en cargas masivas
Buscar publicaciones del vendedor	GET /users/{user_id}/items/search	Para barrer todo el catálogo
Ver un pedido	GET /orders/{order_id}	Comprador, ítems, montos, estado de pago
Buscar pedidos	GET /orders/search?seller={id}	Conciliación y respaldo
Datos de envío	GET /shipments/{shipment_id}	Para sincronizar logística

Con variantes (talle/color) el stock no vive en el ítem sino en cada variation, así que el PUT apunta al array de variaciones. Es el detalle que más rompe integraciones improvisadas.

¿Querés que tu ERP y Mercado Libre hablen sin que vos toques un solo pedido a mano? Agendá una reunión de presentación y te mostramos cómo lo armamos para empresas que venden multicanal.

Paso 3: webhooks de pedidos (la parte que da velocidad)

Acá está el corazón de la automatización. En vez de preguntarle a ML "¿hay ventas nuevas?" cada minuto, dejás que ML te avise. Te suscribís al topic orders_v2 y configurás tu URL de notificaciones. Cuando alguien compra, ML manda un POST como este:

{
  "resource": "/orders/2000003508419013",
  "user_id": 123456789,
  "topic": "orders_v2",
  "sent": "2026-05-25T14:30:00.000-03:00"
}

Fijate que no viene el pedido completo, viene el resource. Tu sistema:

1. Responde 200 al toque (si tardás, ML reintenta y satura tu cola).
2. Encola el resource para procesarlo aparte.
3. Hace GET a /orders/2000003508419013 para traer el detalle.
4. Da de alta el pedido en tu ERP y descuenta el stock.
5. Empuja la nueva cantidad a los otros canales si vendés multicanal.

La regla de oro: respondé rápido, procesá después. Si hacés toda la lógica dentro del request del webhook, cualquier lentitud (una consulta pesada, AFIP caído) hace que ML marque tu endpoint como lento y empieces a perder notificaciones.

Paso 4: red de seguridad con polling de conciliación

Los webhooks son rápidos pero no infalibles: tu servidor se cae, hay un deploy, se cuela un timeout. Por eso ninguna integración seria depende solo de ellos. Sumás un proceso que cada 5-15 minutos consulta /orders/search y compara contra lo que ya tenés cargado. Si aparece un pedido que los webhooks no trajeron, lo recuperás.

Webhooks para velocidad, polling para que no se pierda nada. Esta dualidad es la diferencia entre una integración de demo y una que aguanta el Hot Sale.

Stock y precios desde tu ERP hacia ML

El flujo inverso es igual de importante. Cuando cambiás stock o precio en tu sistema (entró mercadería, ajustaste un margen, se vendió en el local), eso tiene que viajar a ML:

1. Tu ERP detecta el cambio (idealmente por evento, no por barrido completo).
2. Mapeás tu SKU interno al item_id (o variation_id) de ML.
3. Hacés el PUT correspondiente.
4. Registrás la respuesta para auditar y reintentar si falló.

El mapeo SKU ↔ item_id es donde se cae la mitad de los proyectos. Necesitás una tabla de equivalencias confiable y mantenida; sin eso, actualizás el stock de la publicación equivocada. Para repricing competitivo, consultás las publicaciones del catálogo y ajustás dentro de reglas de margen que vos definís: nunca por debajo del costo, nunca arriba de un techo. Si esto vive dentro de un software a medida o de tu CRM a medida, el repricing queda integrado con tus costos reales en vez de ser una planilla aparte.

Cuándo esto NO tiene sentido

Ser honesto ahorra plata. Una integración a medida con la API de ML no se justifica si:

• Vendés menos de 15-20 pedidos por día. El alta manual todavía es más barata que mantener una integración.
• Tenés un solo canal y catálogo chico. Si solo es Mercado Libre con 50 publicaciones, el panel de ML y una planilla alcanzan.
• Tu caso lo cubre una herramienta enlatada. Real Trends, Astroselling o Nubimetrics (USD 30-150/mes) resuelven catálogos simples sin desarrollo. Pagá eso antes de pagar un proyecto.
• No tenés quién mantenga la integración. La API de ML cambia, los tokens vencen, los rate limits se ajustan. Una integración sin dueño se rompe sola en meses.

La integración a medida gana cuando tenés ERP propio, reglas de precio por canal, kits/combos, varios depósitos o facturación atada al pedido. Ahí ninguna herramienta enlatada llega, y el ecommerce a medida sí.

Costos y tiempos reales (2026)

Una integración bien hecha de stock + precios + pedidos contra la API de ML, conectada a un ERP existente, suele tomar entre 3 y 6 semanas de desarrollo. El rango depende de cuántos canales sincronices, si manejás variantes y de qué tan limpia esté tu data de SKUs. El mantenimiento mensual existe y conviene presupuestarlo: la API evoluciona y alguien tiene que seguirle el ritmo.

Integrar tu sistema con Mercado Libre no es magia: es OAuth bien manejado, webhooks rápidos, polling de respaldo y un mapeo de SKUs prolijo. Si tenés volumen y un sistema propio que merece hablar con ML sin intervención humana, empezá tu proyecto con nosotros y te armamos la integración para que cada venta entre sola, el stock nunca mienta y tu reputación quede intacta.