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 recibe una respuesta estructurada en segundos, no en horas.

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 guarda contra el pedido.

Eventos de seguimiento. A medida que el envío se mueve, el transportista empuja 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 marítimo es el que más ha avanzado hacia un estándar compartido. 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. Los transportistas miembros, entre ellos Maersk, MSC, CMA CGM y Hapag-Lloyd, han implementado partes del estándar, lo que significa que una integración construida contra el esquema de DCSA puede servir para más de una naviera con menos mapeo a medida del que habría necesitado hace cinco años. 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 está mucho más fragmentada. 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. Debajo hay un tejido enorme de pymes de transporte y autónomos que siguen funcionando con intercambio electrónico de datos, los mensajes EDI (en inglés), o con una llamada de teléfono, así que una integración de carretera casi siempre tiene que sostener a la vez un camino API y un camino 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, y 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, 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 aplican límites de peticiones estrictos que una página de pago con mucho tráfico puede tocar en pleno Black Friday o en 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. 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. Las actualizaciones de seguimiento llegan cada vez más como webhooks: el transportista llama a tu endpoint cuando cambia un estado, en lugar de que tú preguntes. Es eficiente, pero los webhooks se pierden, se entregan dos veces o llegan 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 girar 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

La mayoría de las empresas no necesita construir integraciones de transportistas desde cero, y algunas sí lo necesitan de verdad. 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 soporta. 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 sale en tres a seis semanas en lugar de convertirse en un proyecto de varios trimestres. 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 cotizar tarifas, crear y confirmar reservas, empujar 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 sostener 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 →