Integración de API de transportistas: tarifas, reservas y seguimiento conectados

La integración de API de transportistas es un enlace directo entre tu software y la plataforma del transportista que intercambia tarifas, confirmaciones de reserva, eventos de seguimiento y pruebas de entrega de forma automática, en lugar de que un responsable de tráfico entre en un portal o espere un correo. Tu TMS (transportation management system, sistema de gestión del transporte), tu página de seguimiento o tu herramienta de reservas llama a la API (application programming interface, interfaz de programación de aplicaciones) del transportista y en muchos casos recibe una respuesta estructurada en segundos, aunque el tiempo real depende del transportista, del servicio y de la disponibilidad de sus sistemas.

La parte de API de transportistas de nuestro trabajo de desarrollo de software logístico a medida cubre esto: qué transporta de verdad la conexión, en qué se diferencian el marítimo, la carretera y la paquetería, qué hace falta para construirla bien y cuándo un agregador en SaaS gana a una integración a medida.

Qué conecta realmente una API de transportista

Quita el lenguaje de folleto y una integración con la API de un transportista mueve cuatro tipos de datos.

Solicitudes de tarifa. Tu sistema envía los datos del envío (origen, destino, peso, dimensiones, nivel de servicio) y la API del transportista devuelve un precio y un plazo estimado de tránsito. Una página de pago de paquetería que muestra el coste de envío en vivo hace justo eso, en tiempo real.

Reserva. Una vez aceptada la tarifa, la API crea el envío en el lado del transportista: una solicitud de recogida, una reserva de contenedor, una adjudicación de carga. El transportista devuelve un número de confirmación que tu sistema asocia al pedido.

Eventos de seguimiento. A medida que el envío se mueve, el transportista envía o expone actualizaciones de estado: recogido, en tránsito, llegado a plataforma, en reparto, retrasado. Esos eventos alimentan tu portal de seguimiento, tus avisos al cliente y tu panel de excepciones.

Prueba de entrega. Cuando el envío llega, la API devuelve la confirmación: una firma, una foto, una marca de tiempo, a veces un documento escaneado. Ese registro cierra el círculo para la facturación y para cualquier reclamación por entrega.

Pocas integraciones tocan las cuatro. Un módulo de pago de paquetería quizá solo necesite tarifas y reserva. Un panel de visibilidad de la cadena de suministro consume sobre todo eventos de seguimiento. Acota la integración al flujo al que sirve, no a todos los endpoints que publique el transportista.

Marítimo, carretera y paquetería: API que no se parecen

Las cuatro funciones de arriba se parecen sobre el papel, pero el marítimo, la carretera y la paquetería las implementan de forma muy distinta, y quien da por supuesto lo contrario se lleva sorpresas rápido.

El transporte marítimo cuenta con iniciativas sectoriales de estandarización, entre ellas las de la DCSA, aunque la cobertura y la adopción varían según la naviera y el módulo. La Digital Container Shipping Association (DCSA) publica especificaciones OpenAPI para seguimiento (track and trace), reserva (booking) y conocimiento de embarque electrónico (eBL), con las definiciones de API de eBL publicadas por primera vez en 2021 y actualizadas a finales de 2023; DCSA orienta estos estándares a la interoperabilidad digital entre navieras y otros actores de la cadena de suministro. En particular, DCSA publica estándares para digitalizar los procesos de booking y conocimiento de embarque, incluidos módulos de emisión, surrender e interoperabilidad entre plataformas eBL. Los transportistas miembros, entre ellos Maersk, MSC, CMA CGM y Hapag-Lloyd, han implementado partes del estándar; DCSA desarrolla estos estándares con grandes navieras y busca facilitar la interoperabilidad, pero la reutilización efectiva de una integración depende de la adopción concreta de cada naviera y del alcance funcional cubierto. Si tu tráfico entra por Valencia, Algeciras o Barcelona, esto es lo que decide si el seguimiento de un contenedor llega solo o lo persigue alguien. La cobertura sigue variando según la naviera y según qué parte del estándar haya sacado.

La carretera presenta una adopción tecnológica heterogénea: algunos operadores ofrecen APIs modernas y otros utilizan EDI u otros canales de intercambio. Los grandes operadores y las bolsas de carga exponen API REST modernas para tarifas y seguimiento: un Dachser (antes Azkar) o una plataforma de cargas del corredor Madrid-Zaragoza-Barcelona te dan datos limpios. Otra parte del sector sigue funcionando con intercambio electrónico de datos, los mensajes EDI, o con una llamada de teléfono; GS1 EDI permite automatizar mensajes comerciales a lo largo de la cadena de suministro y contempla también la gestión del transporte y del almacén. Por eso, una integración de carretera casi siempre tiene que cubrir a la vez una vía API y una vía EDI para el mismo flujo, adjudicación a adjudicación.

La paquetería es lo más parecido a enchufar y funcionar. Los integradores globales (DHL, UPS, FedEx) publican API documentadas para tarificación, generación de etiquetas y seguimiento: como ejemplo documentado, DHL describe integraciones y API para mostrar tarifas en tiempo real, gestionar envíos, reservar, generar etiquetas y consultar el seguimiento. Las redes españolas de paquetería (SEUR, MRW, Correos Express, GLS, Nacex) están integradas en la mayoría de plataformas de ecommerce y agregadores de envíos; Correos indica que su integración por API permite gestionar los envíos y agilizar la logística, el almacén y la atención al cliente, aunque la cobertura de cada API varía: algunas exponen seguimiento y etiquetas, no siempre tarifas en tiempo real. Aquí el problema no es tanto el formato de los datos como el volumen: las API de paquetería pueden aplicar límites de peticiones estrictos; conviene consultar los límites y mecanismos de cada proveedor y diseñar colas, caché y reintentos controlados para picos de tráfico como el Black Friday o las rebajas de enero.

Qué exige construirla: límites, webhooks y reintentos

Una integración de API de transportista que funciona en una demo y otra que sobrevive a una campaña de Navidad no son el mismo software. Cuatro cosas las separan.

Límites de peticiones. Toda API de transportista limita cuántas llamadas puedes enviar por minuto o por día. Si tocas el techo en plena punta, el transportista empieza a rechazar llamadas, a veces sin más aviso que un HTTP 429. El estándar HTTP define el código 429 para indicar que se han recibido demasiadas solicitudes en un periodo determinado y permite incluir el campo Retry-After para indicar cuánto esperar antes de reintentar, según la RFC 6585. Una integración de producción encola y regula las peticiones salientes, y cachea las tarifas durante una ventana corta en lugar de consultar envío a envío.

Fiabilidad de los webhooks. Muchas actualizaciones de seguimiento llegan como webhooks: el transportista llama a tu endpoint cuando cambia un estado, en lugar de que tú preguntes. Es eficiente, pero cuando un proveedor utiliza webhooks, la integración debe contemplar autenticación, duplicados y eventos fuera de secuencia según el contrato técnico de cada proveedor, porque los webhooks pueden perderse, entregarse dos veces o llegar desordenados. Tu endpoint tiene que verificar quién llama y deduplicar por identificador de evento. Y tiene que tolerar eventos fuera de secuencia sin corromper el historial de estados del envío.

Lógica de reintentos. Las API de los transportistas se caen, dan timeout o devuelven un error transitorio en mitad de una llamada de reserva. Reintentar a ciegas puede duplicar un envío. Una buena lógica de reintentos usa claves de idempotencia para que una petición repetida se reconozca como la misma petición. Espacia los intentos y, tras varios fallos, marca el envío para revisión humana en lugar de reintentar sin fin en silencio.

Normalización de datos entre transportistas. Esta es la parte que se come más horas de ingeniería y la que menos se reconoce. El "entregado" de uno es el "completado" de otro. Uno da el peso en kilos y otro en libras. Uno anida el número de seguimiento tres niveles dentro de su JSON y otro lo pone arriba del todo. Una capa de normalización mapea los nombres de campo y los códigos de estado de cada transportista a un único modelo interno de envío, para que el resto de tu software nunca tenga que saber con quién está hablando. Sáltate esa capa y cada transportista nuevo significa condicionales nuevos repartidos por tu página de seguimiento y por tus informes.

Una integración que falla en silencio es peor que no tener ninguna. Cada conexión que merece la pena entregar incluye monitorización que avisa a una persona cuando los datos de un transportista dejan de cuadrar con lo esperado, no solo cuando la propia llamada da error.

Construir o usar un agregador: la respuesta honesta

Muchas empresas pueden valorar un agregador cuando priorizan cobertura rápida y menor carga de mantenimiento; otras necesitan una integración directa por sus sistemas o reglas de negocio. Así distingues en qué lado estás.

Un agregador en SaaS (una plataforma de visibilidad de fletes o un middleware de API de envíos) basta cuando necesitas cobertura amplia rápido, tu equipo no quiere cargar con el mantenimiento de las integraciones y los datos solo tienen que aterrizar en un panel o en una exportación a hoja de cálculo. Esas plataformas ya han construido la capa de normalización sobre decenas de transportistas. Cambias una comisión por envío o por transportista por ahorrarte meses de integración, y ese cambio suele salir a cuenta si tu flujo se parece al estándar.

La integración a medida gana cuando los datos del transportista tienen que entrar directamente en tu propio TMS, tu portal de cliente o tu ERP (SAP, Sage, Odoo, Holded, el que sea) con una forma que el agregador no ofrece; cuando tu volumen encarece la comisión por envío a escala; o cuando necesitas cruzar los datos del transportista con tu propia lógica de negocio (tarifas por cliente, un circuito de incidencias concreto, una traza de auditoría determinada) que ningún panel de agregador contempla. La automatización aduanera que hacemos funciona con el mismo principio: los datos de reserva y de seguimiento alimentan directamente el papeleo de aduanas, y una exportación genérica de agregador no une esas dos cosas.

Construimos estas capas de integración con desarrollo asistido por inteligencia artificial (IA), la práctica que suele llamarse vibecoding, y por eso una integración de API de transportistas acotada puede completarse en unas pocas semanas en lugar de convertirse en un proyecto de varios trimestres, aunque el plazo exacto depende del número de transportistas, del flujo, de la documentación, de las pruebas y de los requisitos de producción. La IA acelera lo repetitivo (clientes de API, andamiaje del mapeo de datos, preparación de tests) mientras nuestros ingenieros se quedan con las decisiones de límites, reintentos y normalización, que son las que deciden si la integración sobrevive al tráfico real.

El camino intermedio también es habitual: un agregador para la cola larga de transportistas que tocas poco, e integración directa para los dos o tres que mueven la mayor parte de tu volumen.

Preguntas frecuentes sobre la integración de API de transportistas

¿Qué es la integración de API de transportistas?

Es una conexión directa entre tu software y el sistema del transportista que intercambia tarifas, reservas, eventos de seguimiento y pruebas de entrega de forma automática. Sustituye las consultas manuales al portal y las confirmaciones por correo por datos estructurados que tu TMS o tu herramienta de seguimiento leen al instante.

¿Qué puede hacer realmente una API de transportista?

Puede consultar tarifas, crear y confirmar reservas, enviar eventos de seguimiento mientras el envío se mueve y devolver la prueba de entrega una vez firmada. Cuáles de estas expone cada transportista depende de la madurez de su API y del servicio que hayas contratado.

¿Todos los transportistas ofrecen API modernas?

No. Las navieras grandes, la paquetería y los operadores de carretera de mayor tamaño publican cada vez más API REST, y organismos como DCSA ya definen formatos compartidos para el marítimo. Muchas pymes de transporte y muchos autónomos siguen con EDI o con métodos manuales, así que la capa de integración suele tener que cubrir ambos.

¿Construimos las integraciones o usamos un agregador?

Usa un agregador cuando necesites cobertura amplia rápido y los datos solo tengan que aterrizar en un panel. Construye a medida cuando los datos del transportista tengan que entrar en tu TMS, tu portal o tu lógica de facturación, o cuando una comisión por envío escale mal con tu volumen.

¿Cómo se gestionan transportistas que envían los datos de forma distinta?

Construyendo una capa de normalización que mapea los códigos de estado, las unidades y los nombres de campo de cada transportista a un único modelo interno de envío. Todo proyecto de integración dedica esfuerzo real a esto, porque no hay dos transportistas que describan igual un "entregado" o un "en tránsito".

Pon precio y fecha a tu integración con transportistas

Cuéntanos con qué transportistas trabajas, qué flujo quieres cubrir y en qué sistemas viven ya los datos de tus envíos. Te respondemos con un alcance cerrado, un precio cerrado y una fecha de entrega medida en semanas.

Pide un presupuesto cerrado →