Relevo · las integraciones
Un sistema que promete integrarse se mide de una sola forma: contando sus rutas. Aquí están contadas.
Su TMS, su sistema de almacén, el portal de la paquetería, el despacho del agente aduanal y el timbrado de la Carta Porte son cinco puertas distintas, y cada una se abre a mano cientos de veces al día. Esta página no argumenta que el sistema se integra: publica el inventario de sus rutas tal como está en la base del motor, con la hora del propio servidor, y dice cuáles de sus campos están vacíos.
El problema, nombrado
Cinco puertas, y ninguna se abre sola
Una operación de transporte internacional no tiene un sistema: tiene cinco ventanas abiertas al mismo tiempo. El sistema de transporte propio, donde vive el viaje. El portal de la paquetería, donde se captura la guía. El despacho del agente aduanal, donde se suben los documentos del cruce. El timbrado, donde nace la Carta Porte. Y el correo, donde el cliente pregunta dónde va su carga.
El costo de eso no es la licencia de ninguna de las cinco. El costo es que el mismo dato —folio, cliente, origen, destino, placas, caja— se teclea cinco veces, y cada tecleo es una oportunidad de que las cinco ventanas dejen de decir lo mismo. Cuando eso pasa, alguien pasa la mañana averiguando cuál de las cinco tiene razón.
No es culpa de su gente. Es que cada una de esas cinco puertas se le vendió por separado, y ninguna se vendió con la obligación de hablar con las otras cuatro. El brochure del sistema lo nombra en su lista de tareas reconocidas desde el primer día: cotización de flete, captura de guía y rastreo con paqueterías, trámite con el agente aduanal, Carta Porte y facturación, y conciliación de pruebas de entrega.
Lo que sigue no discute esa lista. Lo que sigue es el inventario de rutas del sistema de embarques que el motor de la casa tiene generado, contado en su base con la hora del propio servidor, para que usted pueda comprobar el número en lugar de creerlo.
Una integración que hay que consultar no es una integración: es una tarea que alguien tiene que acordarse de hacer.
- El folio del embarque nace una vez y viaja al trayecto, al proveedor y al documento de confirmación de carga.
- El estado del trayecto se actualiza en un solo lugar y el cliente lo ve sin que nadie le escriba.
- La tarifa se compara contra el catálogo del convenio antes de confirmarse, no después de la factura.
- El comprobante fiscal del proveedor se registra contra el trayecto que lo generó, no contra un lote de fin de mes.
- La prueba de entrega se conecta al embarque que sostiene el cobro, y el expediente del embarque cerrado se arma solo.
Mida su operación con esos cinco puntos y sabrá cuántas horas le cuesta a la semana la falta de integración, sin que nadie se lo estime.
Lo que la base dice
1,610 rutas, ninguna repetida
El motor de la casa guarda, para cada sistema que genera, la tabla de sus endpoints. Para el sistema de embarques esa tabla tiene 1,610 filas y 1,610 rutas distintas. Ninguna ruta está repetida: el conteo de filas y el de rutas únicas coinciden exactamente.
Ese es el dato que importa de un inventario de API, porque es el que se puede falsear más fácil. Un catálogo con mil filas y trescientas rutas distintas es un catálogo inflado. Aquí los dos números son el mismo, y la consulta que lo comprueba es una sola línea.
La distribución por método es la de un sistema operativo, no la de un catálogo de lectura: casi dos tercios son consultas, y el tercio restante escribe.
Método HTTP · cuántas rutas · qué hace cada grupo
| Método | Rutas | Qué hace ese grupo en la operación |
|---|---|---|
| GET | 997 | Consulta: bandejas de embarques y trayectos, fichas de proveedor y cliente, catálogos, disponibilidad de activos, historial de auditoría y datos de los tableros. |
| PUT | 279 | Actualización: estado del trayecto, datos de la caja y las placas en la descarga, disponibilidad del activo al cierre, decisión de subcontratación. |
| POST | 214 | Creación y acción: alta de solicitud de embarque, alta de activo, aprobación o rechazo de un ajuste de tarifa, notificación, exportación disparada. |
| DELETE | 69 | Baja: retiro de un registro de catálogo o de un activo, con el historial de auditoría de la baja. |
| sin método resuelto | 51 | Rutas compuestas, del tipo «lectura por GET y guardado por PUT en la misma ficha»: el catálogo las cuenta una vez y las resuelve en dos verbos. |
| Total | 1,610 | 1,610 rutas distintas, ninguna repetida. |
Transcrito de la base del motor de la casa, el proyecto de este sistema, consultado el 27 de septiembre de 2026 entre las 13:50 y las 13:57 h, hora del propio servidor. La hora es parte del dato: un conteo sin hora de corte no es reproducible. El nombre del cliente de ese proyecto está enmascarado en el origen y no se publica.
Las cincuenta y una filas sin método son un hueco real y se dicen. No son rutas inexistentes: son rutas cuya fila guarda dos verbos en un mismo texto de endpoint y por tanto no tiene un identificador de método único. Quien audite esta cifra va a encontrar exactamente eso.
Un inventario que publica sus cincuenta y una filas incompletas es un inventario que se puede auditar. Uno que las esconde, no.
El contrato de la ruta
Qué trae cada ruta, campo por campo
Una ruta sin contrato es una promesa. El contrato de una ruta son cinco cosas: qué versión es, qué se le manda, qué devuelve, con qué código responde cuando sale bien y con qué códigos responde cuando sale mal. La tabla que sigue cuenta, campo por campo, en cuántas de las 1,610 filas está poblado cada uno.
La columna de la derecha es la que hace útil esta tabla. No dice «cumple»: dice el número, y cuando el número es cero lo dice también.
Campo del contrato · cuántas rutas lo traen · valor medido
| Campo | Rutas que lo traen | Valor medido en la base |
|---|---|---|
| Versión de la API | 1,610 de 1,610 | Todas declaran v1. Un solo valor en las 1,610 filas. |
| Esquema de la petición | 1,610 de 1,610 | Documento estructurado con los campos que la ruta espera recibir. |
| Esquema de la respuesta | 1,610 de 1,610 | Documento estructurado con los campos que la ruta devuelve. |
| Códigos de éxito | 1,610 de 1,610 | 200 en todas. |
| Códigos de error | 1,610 de 1,610 | 400, 401, 403, 404, 500, la misma lista en todas: petición mal formada, sin autenticar, sin permiso, no encontrado y fallo de servidor. |
| Exige autorización | 1,610 de 1,610 | Ninguna ruta del sistema es anónima. |
| Exige transporte cifrado | 1,610 de 1,610 | HTTPS obligatorio. |
| Descripción en texto | 1,610 de 1,610 | Cada ruta tiene un nombre de negocio, no sólo un verbo y un camino. |
| Fecha de deprecación | 0 de 1,610 | Ninguna ruta está marcada como retirada: el inventario es de una primera versión, no de una acumulación histórica. |
Transcrito de la base del motor de la casa, el proyecto de este sistema, consultado el 27 de septiembre de 2026 entre las 13:50 y las 13:57 h, hora del propio servidor. La hora es parte del dato: un conteo sin hora de corte no es reproducible. El nombre del cliente de ese proyecto está enmascarado en el origen y no se publica.
Con eso, la pregunta de una integración deja de ser «¿se puede?» y pasa a ser «¿qué ruta y qué campos?». Es una conversación distinta, y mucho más corta.
Los huecos
Qué se fija al integrar con su agente aduanal y su transportista
Esta es la sección que decide si una página de integraciones vale algo. Medir sólo lo que está lleno es hacer publicidad. Lo que sigue son los campos de la misma tabla que están en cero, y están en cero en las 1,610 filas sin excepción.
Conviene leer la tercera columna con cuidado, porque no todos los huecos significan lo mismo. Algunos son una decisión de diseño razonable en una primera versión; otros son trabajo que falta y hay que hacer antes de abrir el sistema a un tercero.
Campo vacío · en cuántas rutas · qué significa el hueco
| Campo vacío | Rutas | Qué significa, y qué falta |
|---|---|---|
| Esquema de autenticación concreto | 0 de 1,610 | Ninguna lo declara, y el encabezado de esta página ya publica ese cero. Conviene leerlo con precisión, porque se presta a entender otra cosa: el vacío está en el campo del catálogo de diseño, no en la puerta. Las 1,610 exigen autorización; se resuelve es decisión de su empresa y se configura contra el que ya use; lo que esta página publica es que la obligación está declarada en las 1,610. |
| Alcance de autorización | 0 de 1,610 | No hay alcances por ruta capturados. El permiso vive en el modelo de roles del sistema, no en el inventario de rutas. |
| Acuerdo de tiempo de respuesta | 0 de 1,610 | Ninguna ruta trae un tiempo máximo comprometido. Publicar un tiempo de respuesta sin este campo poblado sería inventarlo. |
| Límite de llamadas por minuto | 0 de 1,610 | No hay control de caudal declarado por ruta. Es lo primero que hay que definir antes de abrir el sistema a un tercero. |
| Segundos de caché | 0 en las 1,610 | El campo está poblado, con el valor cero: ninguna respuesta se declara cacheable. Es un dato, no un hueco, y conviene no confundirlos. |
| Marca de idempotencia | 0 de 1,610 | Ninguna ruta se declara segura de repetir. En rutas de creación eso importa: un reintento de red puede duplicar un registro. |
| Paginación | 0 de 1,610 | Ninguna ruta se declara paginada y el tipo de paginación es nulo en todas, incluidas las 997 de consulta. Es trabajo pendiente del inventario. |
| Etiqueta de agrupación | 0 de 1,610 | El campo de etiqueta está nulo en todas: la agrupación de esta página se hizo por prefijo de ruta, no por etiqueta declarada, y se dice. |
| Entidad y tabla física asociadas | 0 de 1,610 | El vínculo entre la ruta y la entidad del diccionario de datos no está capturado en esta tabla. Se puede reconstruir por el nombre de la ruta, pero reconstruir no es medir. |
| Tipo de API | 0 de 1,610 | El clasificador de tipo está nulo en todas. No hay distinción declarada entre una ruta de consulta y una de proceso. |
Transcrito de la base del motor de la casa, el proyecto de este sistema, consultado el 27 de septiembre de 2026 entre las 13:50 y las 13:57 h, hora del propio servidor. La hora es parte del dato: un conteo sin hora de corte no es reproducible. El nombre del cliente de ese proyecto está enmascarado en el origen y no se publica.
Que el esquema de autenticación esté vacío en las 1,610 filas no es un descuido de esta página: es el estado de la base, y en otro de los sistemas de la casa el mismo campo aparece vacío en sus doscientos noventa y cinco endpoints. Es un hueco del inventario del motor, igual en todos, y se dice igual en todos.
Los tres huecos que importan para abrir el sistema a un tercero son el mecanismo de autenticación, el control de caudal y la paginación. Los tres son trabajo acotado y ninguno es una decisión de arquitectura: se configuran. Lo que no se puede es publicarlos como si ya estuvieran.
Una página de integraciones que enseña sus diez campos vacíos vale más que una que enseña diez logotipos, porque la primera se puede verificar en media hora.
El mapa
Las familias de ruta: dónde está el trabajo de verdad
Las 1,610 rutas se reparten en 201 familias bajo el prefijo común de la API. Una familia es el primer segmento después del prefijo, y dice de qué habla la ruta. El reparto es el retrato de la operación: donde hay más rutas es donde hay más trabajo que hacer, no donde hay más tecnología.
Las veinte familias mayores concentran la mayor parte del inventario. La tabla agrupa las rutas por tema, con su cuenta al lado, y la tercera columna dice qué área de la operación sostiene cada una.
Familia de ruta · rutas · qué sostiene en la operación
| Familia | Rutas | Qué sostiene |
|---|---|---|
| catálogos | 232 | Clientes, proveedores, activos, conductores, ubicaciones, tarifas, divisas y los catálogos de estatus de cada entidad. |
| embarques | 194 | El registro principal con folio único, su expediente, sus bandejas por rol y su cierre. |
| trayectos | 122 | Cada segmento del embarque: nacional, cruce fronterizo, internacional, con su proveedor, sus recursos y su estado. |
| incidencias | 111 | Lo que se sale del plan durante el trayecto, con su severidad, su escalamiento y su resolución. |
| confirmación de carga | 105 | El documento que se genera por trayecto asignado, su aprobación y su envío al proveedor. |
| proveedores | 98 | Internos y externos, con sus habilitaciones, sus cuentas, sus contactos y su evaluación. |
| disponibilidad | 71 | Qué unidad y qué caja se pueden comprometer, y para cuándo. |
| solicitudes de embarque | 47 | La captura de la solicitud de servicio antes de que exista el embarque. |
| auditoría | 40 | El historial inmutable de quién cambió qué y cuándo. |
| tableros | 37 | Los datos que alimentan los indicadores de operación. |
| activos | 28 | Unidades y cajas propias, con su estado y su ciclo. |
| ajuste de tarifa | 22 | La propuesta de ajuste, su justificación y su aprobación gerencial. |
| autenticación y permisos | 21 | Acceso, selección de rol, permisos de menú y estado de la sesión. |
| órdenes de compra | 38 | El documento del cliente con sus metadatos fiscales, en sus dos familias de ruta. |
| clientes | 18 | El catálogo de clientes con sus datos fiscales y comerciales. |
| reportes | 16 | Las consultas paramétricas con exportación. |
| comprobante fiscal del trayecto | 21 | El comprobante del proveedor por trayecto, en sus dos familias de ruta, para efectos de deducibilidad. |
| conductores | 12 | Licencias, certificaciones y disponibilidad. |
| notificaciones | 33 | Configuración por evento, módulo y rol, y el envío, en sus familias de ruta. |
| ubicaciones | 10 | Origen, destino y puntos intermedios normalizados. |
Transcrito de la base del motor de la casa, el proyecto de este sistema, consultado el 27 de septiembre de 2026 entre las 13:50 y las 13:57 h, hora del propio servidor. La hora es parte del dato: un conteo sin hora de corte no es reproducible. El nombre del cliente de ese proyecto está enmascarado en el origen y no se publica. El agrupamiento se hizo por el primer segmento de la ruta, porque el campo de etiqueta está nulo en las 1,610 filas; dos familias con nombre singular y plural se suman en una sola línea y así se indica.
Fíjese en el orden. La familia mayor no es la del embarque: es la de los catálogos, con 232 rutas. Eso es exactamente lo que pasa en una operación real. El dato maestro —quién es el cliente, qué proveedor está habilitado, qué tarifa aplica a esa ruta, qué caja está libre— es lo que más se consulta y lo que más se corrige, y es donde se origina la mayoría de los errores que después aparecen como una factura glosada.
Y fíjese en la segunda lectura: hay 40 rutas de auditoría y 111 de incidencia. Un sistema que dedica 151 rutas a registrar lo que se salió del plan y quién lo cambió no es un sistema de captura: es un sistema que espera ser auditado.
Si su operación se parece a ese reparto, el sistema ya tiene escrita la ruta que necesita. Si no se parece, el reparto le dice qué le falta antes de firmar nada.
La convención
Las quince operaciones canónicas, y por qué no se multiplican
Hay un argumento que se oye mucho y casi nunca se comprueba: que de cada entidad de datos salen automáticamente sus operaciones. En el motor de la casa ese argumento sí está escrito como dato. Existe un catálogo de convenciones de endpoint con quince operaciones canónicas, cada una con su método, su plantilla de ruta y su plantilla de procedimiento almacenado.
Las quince son éstas, transcritas del catálogo con su plantilla tal cual está guardada:
Operación canónica · método · plantilla de ruta
| Operación | Método | Plantilla de ruta |
|---|---|---|
| listar | GET | /api/{entidad} |
| buscar | GET | /api/{entidad} |
| consultar | GET | /api/{entidad}/{id} |
| crear | POST | /api/{entidad} |
| crear (hijo) | POST | /api/{padre} |
| actualizar | PUT | /api/{entidad}/{id} |
| actualizar (hijo) | PUT | /api/{padre}/{id} |
| eliminar | DELETE | /api/{entidad}/{id} |
| aprobar | POST | /api/{entidad}/{id}/aprobar |
| rechazar | POST | /api/{entidad}/{id}/rechazar |
| cancelar | POST | /api/{entidad}/{id}/cancelar |
| calcular | POST | /api/{entidad}/calcular |
| notificar | POST | /api/{entidad}/notificar |
| exportar | GET | /api/{entidad}/export |
| importar | POST | /api/{entidad}/import |
Transcrito de la base del motor de la casa, el proyecto de este sistema, consultado el 27 de septiembre de 2026 entre las 13:50 y las 13:57 h, hora del propio servidor. La hora es parte del dato: un conteo sin hora de corte no es reproducible. El nombre del cliente de ese proyecto está enmascarado en el origen y no se publica. Catálogo cat_endpoint_convencion, quince filas.
Lo interesante de esa tabla son las siete últimas. Las ocho primeras son las operaciones de siempre. Aprobar, rechazar y cancelar son otra cosa: son operaciones de ciclo de vida, y su existencia como convención explica por qué el sistema tiene veinticuatro pantallas con flujo de aprobación y doscientas trece transiciones de estado sin que nadie las programara una por una.
Y ahora la precisión que evita el error más común. El sistema tiene 53 entidades en su diccionario de datos y 1,610 rutas: eso da treinta rutas por entidad, no quince. La razón es que las entidades centrales —embarque, trayecto, proveedor, incidencia— tienen decenas de rutas propias, mientras que un catálogo de estatus tiene cinco o seis. La proporción se mide por sistema y no se multiplica por una constante. Quien le prometa un número de endpoints multiplicando entidades por quince le está estimando, no midiendo.
Pida el conteo real de su propio proyecto, con la hora del servidor. Es una consulta de una línea y es la diferencia entre un inventario y una estimación.
Más allá de la tabla de rutas
Las otras capas de integración, y las tres que están en cero
El inventario de rutas no es la única capa dondel motor guarda integración. Hay cuatro más, y lo honesto es decir cuáles están poblada para este proyecto y cuáles no. Tres están en cero, y se publican en cero.
La que sí aporta algo distinto es la de los pasos de proceso, porque trae un campo que casi ningún inventario de API tiene: el endpoint de reversión.
Capa de integración · filas para este proyecto · qué significa
| Capa | Filas | Qué significa para este proyecto |
|---|---|---|
| Inventario de rutas | 1,610 | La capa principal. Método, ruta, versión, esquemas y códigos. |
| Pasos de proceso con endpoint | 17, de los cuales 11 con endpoint de reversión | Diecisiete pasos de proceso de negocio tienen su endpoint declarado, y once tienen además el endpoint que deshace el paso. Eso es lo que permite cancelar a mitad de un flujo sin dejar el expediente a medias. |
| Acciones de pantalla con endpoint | 0 | Vacío para este proyecto. En otros sistemas de la casa esta capa está poblada con miles de filas; aquí no lo está, y así se publica. |
| Tareas de servidor con endpoint | 0 | Vacío. No hay procesos programados de servidor dados de alta en este proyecto. |
| Casos de prueba automatizados | 0 | Vacío para este proyecto. En el conjunto de los sistemas de la casa esta tabla tiene decenas de miles de filas; para el proyecto de este sistema tiene cero, y esta página lo dice en lugar de citar el número del conjunto. |
Transcrito de la base del motor de la casa, el proyecto de este sistema, consultado el 27 de septiembre de 2026 entre las 13:50 y las 13:57 h, hora del propio servidor. La hora es parte del dato: un conteo sin hora de corte no es reproducible. El nombre del cliente de ese proyecto está enmascarado en el origen y no se publica.
Los once endpoints de reversión son el hallazgo publicable de esta sección. Un paso que se puede deshacer por una ruta declarada es un paso que se puede cancelar sin llamar a nadie. En una operación donde el embarque se arma con documentos que llegan tarde y se corrigen, eso no es un detalle técnico: es la diferencia entre corregir y volver a capturar.
Y el cero de los casos de prueba se publica tal cual. Es tentador citar la cifra del conjunto de los sistemas de la casa y dejar que el lector la atribuya a éste. No se hace: para este proyecto la tabla está en cero al corte indicado.
Tres capas en cero es información, no un defecto oculto. Lo que invalidaría esta página es que estuvieran en cero y no se dijera.
Del inventario al producto
Qué hace el sistema que aprende con esas rutas
Hasta aquí, un inventario. La parte que le interesa a una operación es qué se hace con él, y aquí es donde el producto del brochure y el sistema generado se juntan.
El brochure describe un producto que observa cómo trabaja el equipo en la computadora, detecta lo repetitivo y lo ejecuta. Para ejecutar una tarea repetitiva hay dos caminos. El primero es imitar los clics de la persona sobre la pantalla, y es el camino que se rompe cuando el portal cambia un botón: el propio brochure nombra ese problema al describir los robots que requieren programadores y se rompen cuando cambia una pantalla.
El segundo camino es llamar a la ruta que está detrás de esa pantalla. Cuando la ruta existe, está versionada, tiene esquema de petición y devuelve códigos de error, la ejecución deja de depender de la posición de un botón. Ese es el sentido de publicar el inventario en una página de producto y no en un anexo técnico.
Las 1,610 rutas no son la promesa del producto. Son la razón por la que la promesa del producto no depende de que nadie mueva un botón.
- Observa — la persona captura la guía en el portal. El sistema registra los pasos y el tiempo, no el contenido del cliente.
- Aprende — detecta que esos pasos se repiten y en qué orden, y los ordena por veces al día y segundos por vez.
- Sugiere — indica el siguiente paso en pantalla mientras la persona trabaja, que es lo que hace productivo al personal nuevo antes.
- Ejecuta — hace la tarea de principio a fin. Donde hay ruta declarada, por la ruta; donde no la hay, sobre la pantalla, y entonces hay que decir que ese camino es más frágil.
- Cuantifica — las horas liberadas por puesto y por equipo, calculadas por el propio sistema, con la evidencia de cada ejecución.
El límite hay que decirlo con la misma claridad. Las rutas medidas son las del sistema de embarques generado por el motor de la casa. El portal de una paquetería ajena, el despacho de un agente aduanal y el timbrado no son de la casa y no tienen inventario publicado por nadie: ahí la ejecución empieza sobre la pantalla, y ésa es la parte que se vuelve a comprobar cada vez que el tercero cambia su interfaz.
Por eso la conversación útil no es «¿se integra con todo?», sino «¿cuáles de mis cinco puertas tienen ruta y cuáles no?». La primera no tiene respuesta verificable; la segunda se contesta en una tarde.
El marco legal
Los datos personales que pasan por una ruta, y la ley que los rige
Un sistema que observa cómo trabajan las personas y mueve datos de clientes por rutas tiene una obligación legal concreta en México, y conviene publicarla con su fecha en lugar de citar unas siglas.
La Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025. Es una ley nueva, no una reforma, y trae un cambio que hay que saber: la autoridad ya no es el organismo garante anterior. Si su aviso de privacidad, su política de uso o su contrato con un proveedor de software nombran a ese organismo, están desactualizados.
Los seis controles de privacidad que el brochure declara se leen distinto a la luz de esa ley, y dos de ellos son de los que se tocan con las rutas: el enmascaramiento de datos sensibles —contraseñas, tarjetas, registro fiscal, clave de población y correos— antes de que salgan del equipo, y el registro del proceso en lugar del contenido.
Control declarado · qué hace · qué obligación legal atiende
| Control | Qué hace | Qué atiende |
|---|---|---|
| Visible y avisado | Cada colaborador sabe que está instalado. | El principio de información: el titular de los datos conoce el tratamiento. |
| Con consentimiento | Política de uso y aviso de privacidad firmados. | El consentimiento expreso y el aviso de privacidad de la ley vigente desde el 20 de marzo de 2025. |
| Datos sensibles ocultos | Contraseñas, tarjetas, registro fiscal, clave de población y correos se ocultan antes de salir del equipo. | El principio de minimización: no sale del equipo lo que no hace falta para la finalidad. |
| Botón de pausa | Para asuntos personales. | La finalidad acotada: lo personal no es objeto del tratamiento. |
| El proceso, no el contenido | Registra los pasos, no la información de sus clientes. | La limitación de la finalidad, y la razón por la que el registro no se convierte en un archivo de datos de terceros. |
| Acceso por rol | Cada jefe ve sólo a su equipo; Recursos Humanos audita. | El deber de seguridad y el control de acceso, con bitácora. |
Controles: brochure de Relevo, sección de privacidad. Norma: Ley Federal de Protección de Datos Personales en Posesión de los Particulares, Diario Oficial de la Federación del 20 de marzo de 2025, verificada al 27 de septiembre de 2026.
Un sistema que observa a personas sin esos seis controles firmados no es un problema de tecnología: es un expediente abierto. Con ellos, es una herramienta de trabajo.
La verificación
Cómo comprobar todo lo anterior
Ninguna cifra de esta página necesita que usted nos crea. Todas salen de una tabla de una base de datos y todas se vuelven a sacar con una consulta corta. Lo que hace verificable el conteo es la hora: el reloj del servidor del motor va por detrás del de la máquina donde se redactó esta página. Por eso cada cifra de aquí lleva la hora del propio servidor.
Lo que puede pedir, y lo que tiene sentido pedir en su caso:
- El conteo de rutas de su proyecto, con la hora del servidor al pie, y el número de rutas distintas al lado del número de filas.
- La lista de campos del contrato poblados y vacíos, tal como está la tabla de esta página, para su propio inventario.
- Las familias de ruta ordenadas por volumen: le va a decir dónde está el trabajo repetitivo de su operación antes de que nadie lo observe.
- Los pasos de proceso con endpoint de reversión, que son los que se pueden cancelar a mitad de camino.
- Y el número que casi nadie pide: cuántas rutas están repetidas. Si filas y rutas distintas no coinciden, el inventario está inflado.
Sobre la verificación de esta página conviene ser explícito en dos cosas. Primero: lo medido es el contenido de la base del motor, es decir el inventario de rutas del sistema generado. No se ejecutó ninguna de las 1,610 rutas, y por tanto esta página no afirma que las 1,610 respondan hoy: afirma que están declaradas con contrato completo, que es un hecho distinto y comprobable.
Segundo: el nombre del cliente del proyecto de este sistema en el motor está enmascarado en la extracción de origen y no aparece aquí, ni el de los proveedores que su operación usa. Eso no es una omisión de conveniencia: es el tratamiento que corresponde a un dato de un tercero, y es el mismo criterio que la ley pide para los datos que el sistema observa.
Si otro proveedor le ofrece integraciones, pídale este mismo inventario con la hora de su servidor. La respuesta, o su ausencia, le va a decir más que cualquier comparación de funciones.
Preguntas frecuentes
¿Las 1,610 rutas responden hoy?
Esta página no lo afirma, porque no se ejecutó ninguna. Lo que se midió es el inventario de la base del motor: 1,610 filas y 1,610 rutas distintas, todas con versión, esquema de petición, esquema de respuesta, código de éxito, códigos de error y autorización obligatoria, al corte del 27 de septiembre de 2026, 13:51 h del propio servidor. Que una ruta esté declarada con contrato completo y que responda son dos hechos distintos, y mezclarlos es lo que hace impublicable un inventario.
¿Con qué mecanismo se autentica una ruta?
No hay dato. Las 1,610 rutas declaran que exigen autorización y transporte cifrado, pero el campo del esquema de autenticación concreto está vacío en las 1,610. Se publica el hueco en lugar de nombrar un mecanismo que la base no dice. El mismo campo aparece vacío en los endpoints de otro de los sistemas de la casa, así que es un hueco del inventario del motor y no de este proyecto en particular.
¿De verdad de cada entidad salen quince endpoints?
El catálogo de convenciones del motor tiene quince operaciones canónicas con su plantilla de ruta, y las rutas reales del proyecto coinciden con ellas. Pero la proporción real de este sistema es de 1,610 rutas sobre 53 entidades, unas treinta por entidad, porque las entidades centrales tienen muchas rutas propias y los catálogos de estatus tienen cinco o seis. La proporción se mide por sistema; multiplicar entidades por una constante da un número inventado.
¿Se integra con el portal de mi paquetería y con el sistema del agente aduanal?
Ésos no son sistemas de la casa y no tienen inventario de rutas publicado por nadie. Lo medido aquí son las rutas del sistema de embarques generado por el motor. Para el portal de un tercero, la ejecución de la tarea repetitiva empieza sobre la pantalla, que es el camino que hay que volver a comprobar cada vez que ese tercero cambia su interfaz. Decirlo así es la única forma honesta de contestar esta pregunta.
¿Puedo abrir estas rutas a un tercero mañana?
Todavía no, y la razón está medida en esta página: faltan tres cosas en el inventario. El mecanismo de autenticación, que está vacío en las 1,610 filas. El límite de llamadas por minuto, que está vacío en las 1,610. Y la paginación, que es nula incluso en las 997 rutas de consulta. Los tres se configuran, ninguno es un cambio de arquitectura, y ninguno se puede publicar como si ya estuviera.
¿Qué pasa con los datos personales que viajan por esas rutas?
La ley aplicable es la Ley Federal de Protección de Datos Personales en Posesión de los Particulares publicada en el Diario Oficial de la Federación el 20 de marzo de 2025, y trae un cambio que conviene revisar en sus propios documentos: la autoridad ya no es el organismo garante anterior. Del lado del producto, los seis controles de privacidad del brochure incluyen el enmascaramiento de contraseñas, tarjetas, registro fiscal, clave de población y correos antes de que salgan del equipo, y el registro del proceso en lugar del contenido de sus clientes.
Referencias
- Base del motor de la casa, tabla de endpoints del proyecto de este sistema en el motor y catálogo de convenciones de endpoint. Consulta de sólo lectura del 27 de septiembre de 2026, corte de servidor 13:50–13:57 h.
- Relevo · brochure de logística, diez páginas: el ciclo de cuatro capacidades, las tareas de logística reconocidas desde el primer día y los seis controles de privacidad.
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares, Diario Oficial de la Federación del 20 de marzo de 2025. Verificada al 27 de septiembre de 2026. ↗
- el motor de la casa, documentación de API pública en disco: referencia para integradores y catálogo de endpoints de orquestación, revisión del 27 de septiembre de 2026.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es Relevo con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.