En una integración entre una aplicación de gestión y WordPress Multisite, la sincronización manual funcionaba, pero los cambios automáticos llegaban a un sitio que no tenía activa la integración. El token era correcto, el endpoint respondía y los datos viajaban. El problema era más sutil: dos identificadores con nombres parecidos representaban cosas distintas.
Un número correcto en el lugar equivocado
La aplicación tenía una tienda interna con un identificador determinado. WordPress, sin embargo, alojaba esa tienda en otro blog_id. El código asumía que ambos valores debían coincidir y enviaba el identificador interno como si también fuera el del sitio WordPress.
La petición llegaba bien, pero WordPress consultaba la configuración de otro sitio y respondía que la sincronización estaba desactivada. Activarla allí habría sido una solución peligrosa: los datos habrían acabado en la web equivocada.
Por qué no cambié simplemente el número
Ese identificador interno aparecía en clientes, mascotas, permisos y relaciones históricas. Sustituirlo de forma masiva podía romper miles de asociaciones. La solución profesional fue separar explícitamente los conceptos:
- identificador interno de la tienda;
- identificador de la tienda utilizado por el negocio;
- identificador del sitio dentro de WordPress Multisite.
A partir de ahí, la aplicación podía mantener intacta su estructura y enviar a WordPress el blog_id correcto.
El preflight que evitó una migración arriesgada
Antes de modificar código o datos, preparé consultas de solo lectura para localizar todas las tablas que utilizaban esos identificadores. También comprobé dominios, rutas, capacidades y usuarios afectados. Esta revisión demostró que el supuesto arreglo rápido habría alterado más de mil clientes y mascotas.
Después añadí el mapeo separado a la configuración y adapté la sincronización para transportar ambos valores de forma explícita. La regla quedó clara: la aplicación decide la tienda de negocio; WordPress decide el sitio donde debe actualizarse el usuario.
Qué revisar en cualquier integración Multisite
- No asumir que
store_id,site_idyblog_idsignifican lo mismo. - Registrar en cada llamada el origen y el destino.
- Validar que el sitio de destino está autorizado para esa tienda.
- No migrar datos antes de contar referencias y dependencias.
- Mantener una tabla de correspondencias cuando los sistemas tienen numeraciones distintas.
Muchas integraciones fallan no porque los datos sean incorrectos, sino porque falta contexto sobre su destino. Un identificador solo tiene sentido dentro del sistema que lo creó.