EDI vs API y otros protocolos de comunicación B2B

Un cliente pide una integración y, de repente, la conversación se llena de siglas: API, FTP, SFTP, FTPS, AS2, X.400, Web Service, EDI. Es habitual pensar que todas compiten entre sí para hacer lo mismo. No es así. 

¿Cuál es la diferencia? EDI define qué información se intercambia y en qué formato; API, SFTP, FTPS, AS2 o X.400 definen cómo viaja esa información de un sistema a otro. Son capas distintas de un mismo proceso, no alternativas excluyentes.

Antes de comparar EDI y API en detalle, conviene tener claro que cada tecnología nació para resolver una necesidad distinta. 

Esta tabla ya adelanta la clave del artículo: EDI vive en una capa (el documento), y el resto de protocolos viven en otra (el transporte). 

EDI (Electronic Data Interchange, o intercambio electrónico de datos) es un estándar para estructurar documentos comerciales, no un protocolo de comunicación. Esta es la distinción que más confusión genera, y también la más importante de todo el artículo. 

Cuando dos empresas se comunican por EDI, no están simplemente «enviándose un archivo»: están usando un lenguaje común para que un pedido, una factura o un albarán generado en el ERP de una empresa sea leído automáticamente por el sistema de la otra, sin intervención manual. 

Existen varios estándares, cada uno con su origen y su ámbito de uso: 

• UN/EDIFACT: desarrollado por Naciones Unidas a través de UN/CEFACT, es el estándar internacional de referencia y el más utilizado en Europa. 

• ANSI X12: desarrollado por el Accredited Standards Committee (ASC) X12 en Estados Unidos, es el estándar dominante en Norteamérica. 

• Subconjuntos sectoriales: como EANCOM (retail, derivado de EDIFACT y mantenido por GS1) u ODETTE (industria del automóvil europea). 

Un intercambio EDI típico entre proveedor y cliente incluye: 

• Pedidos (órdenes de compra) 

• Confirmación de pedido

• Albaranes 

• Facturas electrónicas 

Todos estos documentos se estructuran, no se transportan: para que lleguen a su destino, necesitan viajar sobre alguno de los protocolos que veremos más adelante. Antes de eso, conviene entender la otra pieza del puzle: la API. 

Una API (Application Programming Interface, o interfaz de programación de aplicaciones) es el conjunto de reglas que permite que dos aplicaciones se comuniquen entre sí automáticamente. No define el formato de un documento comercial; define cómo un sistema puede pedirle información a otro y recibir una respuesta. 

Un ejemplo cotidiano en el día a día de una empresa: 

• Un ERP consulta el stock disponible en un marketplace. 

• Una tienda online crea un pedido directamente en el sistema logístico. 

• Una plataforma de transporte actualiza el estado de un envío en tiempo real. 

Hoy, la mayoría de las APIs empresariales son APIs REST, un estilo de arquitectura que usa el protocolo HTTP estándar y suele intercambiar datos en formato JSON, un formato ligero, legible y fácil de integrar en prácticamente cualquier lenguaje de programación. 

EDI y API no compiten por el mismo espacio: EDI estandariza qué se envía, API estandariza cómo se pide y se entrega en tiempo real. Esta tabla resume las diferencias más relevantes: 

Aquí está el matiz que muchas empresas pasan por alto: una API puede transportar perfectamente un mensaje EDI. Cada vez es más habitual que las plataformas de integración expongan una API REST como puerta de entrada, y que internamente esa información se traduzca a EDIFACT o ANSI X12 antes de llegar al socio comercial que sí exige ese estándar. 

Dicho de otro modo: la pregunta «¿EDI o API?» suele estar mal planteada. La pregunta correcta es «¿qué protocolo usaré para transportar mis documentos EDI?», y ahí la API es una opción más, junto a SFTP, AS2 u otros.

SFTP, FTP y FTPS no definen el contenido de un archivo: solo definen cómo viaja ese archivo de un servidor a otro. Son la capa de transporte más básica, y conviene distinguirlas bien porque su nivel de seguridad es muy distinto. 

FTP (File Transfer Protocol) es uno de los protocolos más antiguos de Internet, pensado en la década de 1970 para transferir archivos entre sistemas conectados a una red TCP. Su gran limitación es que transmite tanto las credenciales como los datos en texto plano, sin ningún tipo de cifrado, lo que lo hace vulnerable a interceptación. 

FTPS («FTP over SSL/TLS») toma el protocolo FTP original y le añade cifrado mediante SSL o TLS. Mantiene la misma estructura de dos canales (control y datos) que el FTP clásico, pero cifrados. Existen dos variantes: FTPS implícito (cifrado desde el primer instante) y FTPS explícito o FTPES (el cliente solicita explícitamente pasar a modo seguro). 

A pesar del nombre parecido, SFTP (SSH File Transfer Protocol) no es una versión segura de FTP, sino un protocolo diferente, construido sobre SSH (Secure Shell). Cifra tanto las credenciales como los datos a través de una única conexión, habitualmente por el puerto 22, lo que simplifica mucho su configuración en cortafuegos frente a FTP o FTPS, que necesitan gestionar varios puertos. 

Para el envío de documentos EDI entre socios comerciales, SFTP es hoy la opción más extendida por su seguridad y su facilidad de configuración en cortafuegos. Esto no la convierte automáticamente en la única válida: si un socio ya tiene FTPS implementado por motivos de compatibilidad, sigue siendo una alternativa razonable, siempre con cifrado activado.

AS2 (Applicability Statement 2) es un protocolo diseñado específicamente para transportar documentos EDI de forma segura a través de Internet, con acuse de recibo verificable. Está definido en el estándar RFC 4130 del IETF (Internet Engineering Task Force) y es, junto con SFTP, uno de los protocolos de transporte EDI más utilizados a nivel mundial. 

1. El emisor cifra el mensaje EDI y lo firma digitalmente con su clave privada. 

2. El mensaje se transmite por HTTP o HTTPS hasta el receptor. 

3. El receptor descifra el mensaje, verifica la firma y comprueba su integridad mediante un cálculo hash (MIC). 

4. El receptor devuelve un MDN (Message Disposition Notification), un acuse de recibo firmado digitalmente que confirma que el mensaje llegó correctamente y sin alteraciones. 

Ese MDN es la gran diferencia frente a un simple envío por SFTP: convierte a AS2 en un protocolo con prueba técnica de entrega, algo especialmente valorado en sectores como retail o automoción, donde una disputa sobre si un pedido llegó o no puede tener un impacto directo en la cadena de suministro. 

Antes de que existiera AS2, muchos intercambios EDI viajaban sobre X.400, un protocolo de mensajería que opera sobre redes privadas de valor añadido (VAN), con costes asociados al volumen de datos transmitido. AS2 surgió como una alternativa que ofrece un nivel de seguridad equivalente, pero funcionando directamente sobre Internet, con HTTP como transporte, lo que ha reducido considerablemente su uso en favor de AS2 en la mayoría de sectores. 

Un Web Service es una forma de implementar una API, pero no todas las APIs son Web Services. Es una distinción sutil, pero útil a la hora de leer una propuesta técnica de un socio comercial. 

Los Web Services tradicionales suelen basarse en SOAP (Simple Object Access Protocol) y en mensajes XML, con un contrato muy formal (WSDL) sobre lo que se puede pedir y qué se va a recibir. Son habituales en sistemas corporativos más antiguos y en integraciones que exigen un alto nivel de formalidad y seguridad. 

Las APIs REST modernas, en cambio, son más ligeras, suelen trabajar con JSON y se han convertido en el estándar por defecto para nuevas integraciones, aunque muchas grandes empresas con sistemas legacy siguen operando parcialmente sobre Web Services SOAP. 

Todo lo anterior se resume en una idea sencilla, en forma de esquema: 

EDI define qué se envía y en qué formato. SFTP, API, AS2, Web Service o X.400 son distintos caminos para hacer llegar ese mismo documento a su destino. Una misma factura EDI puede viajar por SFTP a un socio y por AS2 a otro, sin que cambie una sola línea de su contenido. 

• EDI + SFTP: un proveedor envía pedidos en formato EDIFACT a su distribuidor mediante un servidor SFTP, con entregas programadas varias veces al día. 

• EDI + API: un marketplace recibe pedidos a través de una API REST y los convierte internamente a un mensaje EDI antes de enviarlos al ERP del vendedor. 

• EDI + AS2: un fabricante de automoción intercambia avisos de expedición con su cliente mediante AS2, con acuse de recibo MDN como prueba de entrega. 

• EDI + Web Service: una integración con un sistema legacy corporativo que solo admite conexiones SOAP. 

No existe una respuesta única. Depende del socio comercial, del sector y del volumen de documentos. 

En la práctica, casi ninguna empresa B2B usa una sola de estas tecnologías: la mayoría combina varias, en función de con quién esté hablando cada sistema. 

En estos casos, cobra gran importancia contar con un proveedor EDI como nexmart, ya que simplifica de cara al proveedor un único formato y método de comunicación, facilitando así la comunicación con diversos tipos de clientes, tecnologías, mensajes y formatos.

La conversación sobre EDI vs API está cambiando de enfoque. Ya no se trata de sustituir un estándar por otro, sino de combinarlos: 

• Las APIs ganan terreno para integraciones cloud y conexiones en tiempo real entre aplicaciones internas. 

• El EDI se mantiene como el lenguaje de referencia para el intercambio documental B2B, especialmente donde hay obligaciones normativas o estándares sectoriales muy asentados. 

• Cada vez más plataformas ofrecen arquitecturas híbridas, donde una API sirve de puerta de entrada y el EDI sigue siendo el formato final del documento. 

El EDI y el API no llevan a cabo la misma función, son sistemas complementarios. EDI define el lenguaje del documento comercial; API, SFTP, FTPS, AS2, Web Service o X.400 son las distintas vías para hacerlo llegar a su destino. Entender esta separación, contenido por un lado, transporte por otro, es lo que permite a una empresa B2B elegir la combinación adecuada para cada socio comercial, en lugar de buscar una única tecnología que lo resuelva todo. 

Si tu empresa está valorando contratar una solución EDI, puedes contactarnos a través de nuestro formulario y te ayudamos a encontrar la combinación que mejor se adapte a tus socios comerciales.

No. Resuelven necesidades distintas: EDI estandariza el documento, la API estandariza la comunicación entre sistemas. Es habitual que convivan en la misma integración.

No. SFTP es un protocolo de transporte de archivos. EDI es el estándar que define el contenido de esos archivos. Se pueden usar juntos, pero no son lo mismo.

Sí. Es una práctica cada vez más habitual: la API actúa como puerta de entrada y, detrás, el sistema convierte la información al estándar EDI que requiera el socio comercial.

SFTP. FTP transmite datos y credenciales sin cifrar, mientras que SFTP cifra toda la comunicación a través de SSH (Secure Shell).

Ambos transportan documentos EDI de forma segura, pero AS2 añade firma digital y un acuse de recibo (MDN) que certifica que el mensaje llegó íntegro, algo que SFTP no ofrece de forma nativa.

Noticias similares