Hemos integrado RANDOM ERP con Mercado Libre en cuatro empresas distintas, todas con conexión directa contra la API del marketplace. Los rubros eran diferentes y los problemas terminaron siendo casi los mismos.
Lo que sigue es lo que uno querría saber antes de empezar, no después.
El problema que casi nadie dimensiona bien
La sobreventa. Vendiste en Mercado Libre una unidad que ya se había vendido en el mostrador hace veinte minutos.
Suena a detalle operativo y no lo es: en Mercado Libre las cancelaciones por falta de stock afectan la reputación del vendedor, y la reputación determina cuánto te muestra el marketplace. Un problema de sincronización de bodega termina afectando las ventas de todo el catálogo.
Toda la arquitectura de la integración se ordena alrededor de evitar eso. El resto son detalles.
Las cinco decisiones
1. Quién es dueño del stock
La respuesta corta es el ERP, siempre. Pero hay que ser explícito, porque el marketplace también lleva su propia cuenta y las dos van a diferir en algún momento.
Lo que funciona: el ERP es la única fuente de verdad y publica cambios hacia Mercado Libre. Nunca al revés. Cuando llega una venta, el marketplace no descuenta stock: informa una venta, y el descuento lo hace el ERP con su propia lógica de reservas y bodegas.
Y una decisión que hay que tomar sí o sí: cuánto del stock real se expone. Publicar el 100 % de las unidades disponibles es la receta más rápida para sobrevender cuando también hay venta presencial. Un colchón, o una bodega lógica dedicada al canal online, resuelve el 90 % del problema sin una línea de código adicional.
2. Cómo se mapean los SKU
Es la parte más aburrida y la que más proyectos atrasa. El código del producto en el ERP y el identificador de la publicación en Mercado Libre son cosas distintas, y la relación casi nunca es uno a uno.
Los casos que siempre aparecen: un mismo producto publicado varias veces, packs que en el ERP son varios productos y en el marketplace son uno solo, variantes de talla o color que el ERP maneja como códigos independientes.
La tabla de mapeo hay que construirla y hay que mantenerla. Conviene que viva en el ERP, que sea visible para quien administra el catálogo y que el sistema avise cuando aparece una publicación sin producto asociado. Si el mapeo vive en la cabeza de una persona, el proyecto tiene fecha de vencimiento.
3. Cuándo se emite el documento tributario
Acá es donde la integración deja de ser un tema de sistemas y pasa a ser un tema contable. Cada venta necesita su boleta o factura electrónica, y hay que definir con precisión en qué momento se emite: al confirmarse la venta, al despacharse, o al acreditarse el pago.
No es una preferencia técnica. Define cómo cuadra la contabilidad, qué aparece en el Registro de Compras y Ventas y qué pasa cuando una venta se cae después de emitido el documento.
La recomendación práctica: que el DTE lo emita el ERP, no un sistema aparte. Si el marketplace o un tercero emite documentos por su cuenta, terminas con dos fuentes de numeración y una conciliación mensual que nadie quiere hacer.
4. Qué pasa con las devoluciones
Es el flujo que se deja para el final y el que más duele después. Una devolución en Mercado Libre tiene que producir tres cosas en el ERP: la nota de crédito, el reingreso del stock a la bodega correcta y el ajuste del costo de venta.
Si eso queda manual, funciona bien mientras las devoluciones sean pocas. El día que hay una campaña grande, se acumulan y alguien las procesa dos semanas después, con el stock mal informado todo ese tiempo — y ahí volvemos al problema de la sobreventa.
5. Quién administra las publicaciones
Dos caminos válidos y hay que elegir uno.
Crear y editar publicaciones desde el ERP da control total y catálogo consistente, pero obliga a modelar en el ERP cosas que son propias del marketplace: fotos, descripciones, atributos de ficha, categorías. Es más trabajo.
El otro camino es administrar las publicaciones en Mercado Libre y que la integración sincronice solo stock y precio. Es mucho más liviano, y para la mayoría de las empresas es suficiente. Nuestra recomendación por defecto es partir por ahí y crecer si se justifica.
Tres cosas de la API que conviene saber antes
Notificaciones, no consultas periódicas
Mercado Libre notifica los eventos hacia tu sistema. Construir la integración preguntando cada cierto tiempo «¿hay ventas nuevas?» funciona en las pruebas y se cae con volumen: o llegas tarde o generas una cantidad de llamadas innecesarias.
El punto fino es que las notificaciones pueden llegar duplicadas o desordenadas. Cada operación tiene que ser idempotente: procesar dos veces el mismo aviso de venta no puede generar dos descuentos de stock ni dos boletas. Se resuelve guardando el identificador de cada evento ya procesado, y es de las cosas que hay que hacer bien desde el primer día.
El manejo de tokens es más delicado de lo que parece
El token de acceso de Mercado Libre dura seis horas. El token de refresco dura seis meses y es de un solo uso: cada vez que lo usas recibes uno nuevo, y solo el último sirve.
Eso tiene una consecuencia práctica incómoda. Si dos procesos intentan refrescar el token al mismo tiempo, uno de los dos se queda con un token inválido y la integración se cae sin razón aparente. La renovación tiene que estar centralizada y protegida contra concurrencia.
El día que el cliente cambia su contraseña
Este es el que hay que dejar anotado. Los tokens se invalidan antes de tiempo cuando cambia la contraseña de la cuenta, cuando se revocan permisos o cuando se toca la aplicación conectada.
Nadie del área comercial sabe que cambiar la clave de Mercado Libre bota la integración. Lo va a hacer un viernes, y si el sistema no avisa, el lunes hay dos días de ventas sin descargar y stock desactualizado.
Por eso una integración de marketplace sin monitoreo no está terminada. Tiene que avisar sola, a una persona con nombre y apellido, cuando lleva más de X minutos sin poder autenticarse. Eso vale más que cualquier funcionalidad extra.
¿Directo contra la API o con un middleware?
Existen conectores intermedios que resuelven parte de esto, y no está mal usarlos. La comparación honesta:
Directo contra la API
Lo que hicimos en los cuatro casos
- Control total sobre la lógica de stock y reservas
- Sin costo recurrente por canal ni por transacción
- La lógica particular del negocio se puede modelar tal cual es
- Requiere mantener la integración cuando la API cambia
Con middleware
Multivende, Centry y similares
- Más rápido de poner en marcha
- Varios marketplaces con un solo desarrollo
- Costo mensual permanente
- La lógica de stock es la que trae el conector, no la tuya
La regla que usamos: si vendes en un solo marketplace y tu lógica de stock tiene particularidades — reservas, bodegas múltiples, productos que se arman —, la conexión directa sale mejor. Si vendes en cuatro marketplaces y tu operación es estándar, el middleware probablemente te conviene.
Lo que no recomendamos es decidirlo por precio inicial. El costo real de un middleware aparece al tercer año, y el costo real de una integración directa aparece cuando nadie la mantiene.
Cómo lo abordamos
Levantamiento del flujo real
Cómo se vende hoy, qué bodegas hay, quién toca el stock y en qué momento se emite el documento. Sin esto, cualquier integración es una apuesta.
Mapeo de productos
Construir y validar la tabla de correspondencia entre el ERP y las publicaciones. Es la etapa que más se subestima.
Sincronización de stock y precio
El primer tramo en producción, en una dirección, con colchón de seguridad. Resuelve el problema más grande antes que nada.
Descarga de ventas y emisión del DTE
Las ventas entran al ERP y generan su documento tributario, de forma idempotente.
Devoluciones y monitoreo
Notas de crédito, reingreso de stock y las alertas que avisan cuando algo dejó de funcionar.
¿Se puede integrar RANDOM ERP con Mercado Libre sin cambiar de ERP?
Sí. En los cuatro casos que hemos hecho, el ERP siguió siendo RANDOM y la integración se construyó alrededor. Cambiar de ERP para vender en un marketplace casi nunca se justifica.
Lo que sí hay que revisar antes es cómo el ERP maneja bodegas, reservas y numeración de documentos, porque de eso depende el diseño.
¿Cuánto demora una integración así?
El desarrollo es la parte corta. Lo que define el plazo es el mapeo de productos y qué tan ordenado esté el catálogo: con un catálogo limpio se avanza rápido, con uno desordenado la etapa de mapeo puede durar más que todo el resto.
Por eso partimos siempre por stock y precio: pone valor en producción temprano mientras el resto avanza.
¿Qué pasa si vendemos también en tienda física?
Es justamente el caso donde la sobreventa es un riesgo real, y hay que resolverlo con reglas de negocio antes que con tecnología: bodega lógica dedicada al canal online, o un colchón de unidades que no se publica.
La sincronización más rápida del mundo no resuelve dos ventas simultáneas de la última unidad.
¿Sirve lo mismo para Falabella, París o Ripley?
El diseño sí: stock como fuente única, mapeo de SKU, idempotencia, emisión del DTE y monitoreo se repiten en todos los marketplaces.
Lo que cambia es la API de cada uno. Si el plan es vender en varios canales, conviene diseñar la integración pensando en eso desde el principio en vez de resolverlo canal por canal.
¿Quién queda a cargo de la integración después?
Es la pregunta que hay que dejar cerrada en el contrato. Una integración de marketplace es algo vivo: las APIs cambian y las cuentas se reautentican.
En nuestro caso el código y las credenciales quedan a nombre del cliente, y la mantención se acuerda aparte del desarrollo para que sea explícita y no una sorpresa.
¿Estás evaluando vender en Mercado Libre con tu ERP?
Lo hemos hecho cuatro veces y sabemos dónde se cae. Te invitamos a tomarnos un café: nos cuentas cómo funciona hoy tu operación y te decimos qué camino conviene en tu caso, incluso si ese camino no nos incluye. Sin costo ni compromiso. Conversemos.