Vender en un marketplace social parece un problema de marketing. En realidad es un problema de fontanería: alguien compra a las once de la noche en TikTok, y a esa venta le corresponde un producto que está en un almacén, en un sistema que no sabe nada de TikTok.
Si esa conexión no existe, aparecen las tres consecuencias de siempre: se vende lo que ya no hay, los pedidos se capturan a mano, y el almacén no puede despachar hasta que alguien busca la etiqueta en un panel del marketplace.
Cada una de esas tres cosas cuesta dinero todos los días, y ninguna se resuelve contratando más personal.
No es una tienda ni un panel: es el middleware que vive entre TikTok Shop y los sistemas internos de Cloe, y que hace que las dos partes se comporten como si fueran una sola. Cierra el ciclo completo.
Cuando cambia la existencia de un artículo, el sistema de Cloe deja el aviso y el middleware lo publica en el marketplace — con una política antisobreventa que va más allá de copiar el número.
Alguien compra a las once de la noche. El pedido aparece en el sistema de Cloe sin que nadie lo capture, con sus renglones, sus descuentos y sus fechas límite.
Cuando el paquete está listo, el almacén recibe la guía de envío ya generada y descargada. Nadie tiene que ir a buscarla al panel del marketplace.
Si el comprador cancela, el almacén se entera a tiempo para deshacer el surtido en vez de despachar un pedido que ya no existe.
Ese es exactamente el objetivo de un sistema como este: si funciona, es invisible. La medida de su éxito es que el equipo de Cloe no piensa en él.
En una semana el sistema ya procesaba pedidos; en dos, cerraba el ciclo hasta la etiqueta de envío. Un mes después de arrancar estaba terminado, con su capa de vigilancia y sus alertas.
Ocho meses en producción sin necesitar un solo cambio. Para una integración contra la API de un tercero que evoluciona por su cuenta, esa estabilidad es el resultado, no un detalle.
El cliente que se conecta al marketplace es de desarrollo propio, y es la segunda versión: la primera la escribimos en PHP para otro cliente, dentro de un ecosistema completamente distinto.
Eso significa que Cloe no pagó una curva de aprendizaje, sino la aplicación de una que ya estaba pagada. No es que hayamos hecho una integración con TikTok Shop: conocemos la plataforma lo bastante como para haberla resuelto dos veces, en dos lenguajes y dos arquitecturas, para dos sectores distintos.
Ver la otra integraciónUn proyecto pequeño no significa un proyecto fácil. Estos son los siete problemas que había que resolver bien para que el sistema pudiera quedarse solo.
TikTok Shop rechaza toda petición cuya firma no reproduzca exactamente su canonicalización: ruta, más parámetros ordenados alfabéticamente excluyendo dos concretos, más el cuerpo, todo envuelto en el secreto de la aplicación. Cuando no cuadra, la API solo responde «firma inválida», sin decir por qué.
El cuerpo hay que firmarlo tal cual se envía. Si se serializa dos veces y el orden de las claves cambia, la firma no cuadra.
Se serializa una sola vez y esa misma cadena se firma y se manda. El error deja de ser posible.
El endpoint de autorización usa una ruta de firma distinta, y está escrito como tal en lugar de forzarlo por el camino común.
Un día entero de trabajo dedicado casi por completo a la firma y los tokens, con decenas de intentos probados contra la API real.
Es lo que cuesta integrarse con una plataforma que solo te dice que no.
Los tokens de acceso expiran. Una expiración desatendida deja de sincronizar inventario y de recibir pedidos, en silencio, hasta que alguien lo nota por el lado del negocio.
Se valida la expiración guardada contra la hora actual, con zona horaria explícita.
Aunque parezca válida, se hace una llamada sonda: si la plataforma repudia el token, se fuerza la renovación.
Un proceso programado renueva de forma proactiva, al margen de que haya tráfico o no.
Tres capas para que la integración nunca dependa de que alguien se acuerde.
El marketplace avisa en tiempo real cuando hay una venta. Pero una caída, un despliegue o un fallo de red convierten ese aviso en un pedido que no existe para el almacén.
El aviso en tiempo real, y un barrido periódico que recorre todos los pedidos pendientes de envío y añade los que falten.
Ambos escriben por la misma función, que comprueba existencia antes de insertar. Da igual quién llegue primero.
Del aviso solo se usan qué pedido cambió y a qué estado; todo lo demás se vuelve a pedir a la plataforma.
El sistema puede estar caído: al volver, recupera lo que se perdió.
La integridad no depende de que ningún mensaje llegue.
Publicar el stock real produce sobreventa, porque entre que el almacén despacha y el marketplace se entera pasa tiempo. Y sobrevender en un marketplace no solo pierde la venta: penaliza la cuenta.
Cuando quedan pocas piezas se publica cero y se despublica el producto; al reponer, se reactiva.
Se consulta cómo está el producto en el marketplace antes de actuar, para no gastar llamadas ni provocar errores.
La cola se desduplica en la propia consulta, así que un artículo que cambió diez veces se sincroniza una.
El colchón absorbe el desfase entre el almacén y la plataforma.
El sistema de Cloe conoce artículos que no están publicados en el marketplace. Si el proceso simplemente fallara, la cola se bloquearía y el error se repetiría indefinidamente.
Ni pendiente ni sincronizado, sino inexistente en el marketplace.
El artículo no publicado deja de ser un bloqueo y pasa a ser un dato.
Un registro consultable de qué artículos no existen allí — justo lo que el equipo comercial necesita saber.
Un fallo silencioso convertido en información de negocio.
Confirmar el envío de un paquete cambia su estado, pero el número de guía y el PDF de la etiqueta no existen todavía en ese instante. Y el almacén necesita la etiqueta para despachar.
Confirmar cada paquete, esperar, volver a consultar el pedido para leer el número de guía recién asignado y persistirlo.
Se reintenta solo ante el error concreto que significa «aún no está lista»; ante cualquier otro, se aborta sin insistir.
El documento se descarga, se codifica y se devuelve en la misma respuesta, además de guardarse.
Si tarda más que la ventana de espera, un proceso posterior barre los paquetes que quedaron sin documento.
El almacén recibe su etiqueta, o la recibe poco después, sin volver a pedir nada.
Sin interfaz, los fallos son silenciosos por definición. Y el endpoint tiene que estar expuesto a internet por obligación, porque el marketplace debe poder alcanzarlo.
Con rotación y retención automática, para que el diagnóstico no dependa de tener el terminal abierto.
Cualquier error no controlado publica su traza, su origen y su contexto donde alguien lo va a ver.
Cada petición a una ruta inexistente se clasifica como escaneo automatizado o como error real, comparando contra rutas típicas de sondeo y firmas de herramientas conocidas.
Con ambos bloques por separado: los errores reales indican integraciones rotas; el resto es ruido de internet.
Un sistema invisible necesita más vigilancia que uno con pantallas, no menos.
Todo lo de esta lista existe en producción, sincronizando ventas reales todos los días.
Ver todos nuestros serviciosEste es el proyecto más pequeño de nuestros casos publicados, y está construido con la misma disciplina que los grandes: idempotencia, tolerancia a fallos, reintentos que distinguen qué merece reintentarse, y vigilancia de un sistema que nadie va a mirar.
Un encargo acotado recibe las mismas decisiones de ingeniería que uno de dos años. Cambia el alcance, no el criterio.
Lo que resolvimos para un cliente acelera al siguiente. No se reutiliza su código: se reutiliza el conocimiento de la plataforma.
El proyecto se cerró con su capa de vigilancia y sus alertas puestas, no cuando la funcionalidad empezó a responder.
Por eso pudo pasar ocho meses en producción sin que nadie tuviera que abrirlo.
Si capturas pedidos en tu sistema copiando de un panel, o descubres la sobreventa cuando el cliente ya compró, es exactamente el problema que sabemos resolver.