La pregunta nunca es realmente «¿API o EDI?». Es «¿cuáles de mis transportistas pueden enviarme siquiera un mensaje de estado, y en qué formato?». Un cargador europeo con cuarenta transportistas suele acabar manteniendo ambos canales a la vez, porque los cinco principales pueden sostener un mapeo EDI y los otros treinta y cinco no. Esa es la situación para la que se diseña una API de visibilidad del transporte por carretera en tiempo real y es la razón por la que la elección importa menos de lo que dan por hecho la mayoría de los proyectos de integración.
Lo que sigue es la comparación tal como se desarrolla en una ruta europea, no como un debate de protocolos.
Qué es cada uno en realidad
EDI es un conjunto de formatos de mensaje acordados más una forma acordada de mover los archivos. En el transporte por carretera europeo eso casi siempre significa EDIFACT: IFTMIN para cursar una instrucción de transporte, IFTSTA para informar del estado, IFTMAN para el aviso de llegada, DESADV para el aviso de expedición contra el que da entrada el almacén receptor. Los archivos se mueven por AS2, SFTP, OFTP2 en automoción, o a través de una red de valor añadido que cobra por volumen. Una conexión con un socio es un proyecto con una especificación, un mapeo y un ciclo de pruebas.
Una API es un endpoint al que su sistema llama, o que le llama a usted. JSON sobre HTTPS, un token para la autenticación, un conjunto documentado de campos y ninguna especificación por socio, porque la especificación es la misma para todos. Donde el EDI negocia un formato por relación, una API publica un único formato y pide a los socios que lo cumplan.
Ambos transportan los mismos datos. La diferencia está en la forma del trabajo: el EDI traslada el coste a la conexión; una API lo traslada a la integración que construye una sola vez.
Por lotes frente a por eventos
Esta es la distinción que lo decide todo aguas abajo, y se pierde cuando la comparación se plantea como lo viejo frente a lo nuevo.
El EDI tiene forma de archivo. Los mensajes se acumulan y se transmiten según una planificación, habitualmente cada quince minutos o cada hora, a veces durante la noche para tipos de mensaje no urgentes. Aunque la ventana de transmisión sea corta, el patrón es un lote: llega un archivo, se analiza y todo lo que contiene se procesa de golpe.
Una API tiene forma de evento. Una posición o un cambio de estado se envía en el momento en que se conoce, o se solicita cuando usted lo pide. El intervalo entre que el camión cruza el geoperímetro y que su TMS se entera es de segundos, en lugar del resto de la ventana del lote.
Para la facturación y el aviso de expedición, el lote está bien y siempre lo ha estado. Para cualquier cosa sobre la que un operador de tráfico actúe dentro de la hora, la latencia del lote es el problema entero. Aquí también se concreta la diferencia entre visibilidad y seguimiento : un archivo IFTSTA nocturno le da un registro, no visibilidad.
Qué puede soportar realmente un transportista pequeño
Los planes de integración fracasan aquí más a menudo que en ningún punto técnico.
Un transportista con doscientos camiones y un equipo informático puede mantener un mapeo EDI, absorber un cambio de formato y probar un nuevo tipo de mensaje. Un transportista con doce camiones no puede, y en la mayoría de las redes europeas el operador de doce camiones es la mayoría de sus socios por número, aunque los grandes transportistas sean la mayoría por volumen.
Lo que el transportista pequeño sí tiene es una caja telemática, porque el tacógrafo y el contrato de gestión de flotas ya han puesto una en la cabina. Esa caja tiene una API. Conectarse una vez al proveedor de telemática le da datos de posición de todos los abonados de ese proveedor, y por eso la visibilidad mediada por plataforma escala donde el EDI bilateral no lo hace: una integración, muchos transportistas, sin un proyecto por relación.
La consecuencia práctica es que un cargador que elige EDI en exclusiva está eligiendo tener visibilidad sobre el quince por ciento superior de su base de transportistas y nada sobre el resto.
Coste y tiempo, con honestidad
Los costes del EDI están en tres sitios. Está la puesta en marcha de cada conexión con un socio, normalmente de cuatro a doce semanas desde la especificación hasta producción para un par de mensajes con un socio que ya lo ha hecho antes, y más con uno que no. Está el propio mapeo, que es trabajo a medida cada vez que un socio interpreta un segmento de forma distinta, y lo hacen. Luego está el coste de funcionamiento: la red de valor añadido cobra por volumen de datos, o el coste interno de una pila AS2 a la que alguien tiene que mantener los certificados en vigor.
Los costes de una API están en un solo sitio y luego se acaban. La integración se construye una vez contra un endpoint documentado. Añadir el transportista número cuarenta y uno cuesta una cuenta y una llamada de prueba, en lugar de un proyecto. El coste recurrente es la monitorización, que de todos modos necesitaba.
La asimetría honesta está al principio: si el socio ya tiene EDI con usted y el mensaje ya existe, usarlo es casi gratis, y reconstruir ese flujo como una API no aporta nada. Nadie debería migrar un flujo INVOIC que funciona por pulcritud arquitectónica.
Dónde sigue ganando el EDI
Cuatro situaciones, y no son casos extremos.
- Cumplimiento en el retail. Cuando una cadena de alimentación o de bricolaje impone DESADV y una etiqueta concreta, ese es el canal. No hay alternativa API disponible y el régimen de penalizaciones es real.
- Automoción. OFTP2 y el conjunto de mensajes Odette están incrustados en la cadena de suministro y en las expectativas de auditoría que la rodean. Los flujos de call-off y de instrucción de entrega no se mueven.
- Volumen que es genuinamente por lotes. Autofacturación mensual, conciliación de facturas de transporte, tablas de tarifas. Un archivo es la forma correcta para esto y una API no añade más que llamadas.
- Peso legal y de archivo. Donde el mensaje tiene que archivarse en una forma estructurada acordada durante años, un archivo EDI maduro es un problema resuelto. El mismo argumento se aplica a las cartas de porte, que es una discusión aparte tratada en la comparación de eCMR y carta de porte CMR.
Usar ambos sin pagar dos veces
La arquitectura que funciona no es una migración, es una capa de traducción. Ambos canales aterrizan en el mismo sitio, se normalizan en el mismo evento interno y los sistemas aguas abajo nunca llegan a saber de qué canal llegó un evento dado.
Tres reglas lo mantienen en pie:
- Un único modelo de evento interno. Una llegada es una llegada tanto si viene de un segmento IFTSTA como de un webhook. Defina el conjunto de campos una sola vez, incluida qué marca temporal es la autoritativa, y mapee hacia él en el borde. Sáltese esto y tendrá dos verdades paralelas, que es peor que cualquiera de los dos canales por separado.
- Idempotencia en la frontera. Los archivos EDI se reenvían y los webhooks se reintentan. Cada evento entrante necesita una clave que haga inocuo el reprocesamiento; de lo contrario, un archivo reenviado reescribe el historial con llegadas duplicadas y cada cifra de permanencia que publique estará mal.
- Un único informe de conciliación. Cuente los eventos por transportista, por semana y por canal. Este es el informe que revela a un transportista que dejó de enviar hace tres semanas, que es el fallo silencioso más común en ambos canales y la razón por la que la cifra de un panel de KPI de transporte por carretera se desvía sin que nadie la toque.
La ruta de migración, cuando la hay, discurre socio a socio en la dirección de menor resistencia. Mueva a un socio cuando su mapeo EDI ya tenga que cambiar de todos modos, nunca como un proyecto en sí mismo. Mantenga el flujo EDI activo en paralelo durante un mes y compare los recuentos de eventos antes de pasar a los consumidores aguas abajo. Retire el mapeo solo cuando los recuentos hayan coincidido durante cuatro semanas.
La decisión en sí es más pequeña de lo que parece. Elija el canal que cada socio pueda sostener realmente, normalice ambos en un único modelo de evento y dedique el esfuerzo ahorrado a la parte que de verdad determina si algo de esto funciona: cuántos de sus transportistas están conectados siquiera, y si los eventos que envían son fiables. Esa pregunta, no el protocolo, es lo que separa un programa de visibilidad que funciona de un proyecto que produjo una especificación. Dónde alojar los flujos resultantes es una elección relacionada pero distinta, expuesta en la guía de los modelos 3PL y 4PL.
