Some time ago I set myself to a quest to find out if there was a unified transport API/EDI standard which is in use by several logistics companies. Surely in this day and age, something like that must exist, right? A universal shipping API format?

Well, long story short, it does not exist. 

The closest you can get is some API provider who has built lots of carrier API connections and then offers its own API endpoint to access different transport service providers.

In this article, I will cover a few different carrier APIs, briefly describe their capabilities, and discuss ways to implement them.

NB! If you’re just looking for a universal transport API protocol, here’s a link where you can book a quick call with me.

Anyway, let’s start with a…

 
First, let's define the goal.

Consider an average manufacturer with both domestic and international customers and suppliers. Goods need to be picked up from suppliers and delivered to the production site, while the final products need to be shipped to customers.

To establish a reliable supply chain, your typical mid-sized manufacturer would need 10-20 transport partners:
 

 
Managing all those relationships is complex enough. But the real fun starts when you try to integrate their IT systems! (since there’s no unified freight API protocol)

Secondly, we need to agree on the scope.

Not all logistics companies offer the same service level. Some have very sophisticated APIs providing instant freight pricing, booking, labels, tracking, courier requests, etc., while others might only have a portal where you can log in and submit a booking. Some don’t have any IT systems at all—only email. For our target scenario, let’s keep things simple and just aim to:

Sounds simple enough, right? Oh, if only...

 
The manual way of handling things, which appears to be the industry standard for most companies, involves using carrier portals wherever possible and communicating via email with the rest of the transport partners. In our example, we assume that transport pricelists, schedules, lead times, and invoice handling are managed separately. For booking submissions, we aim to build an API connection from our ERP system.

Let's assume we have selected the following list of transport companies and need to build a direct API connection to their systems from our ERP software. This selection is random and covers only a fraction of the different carrier APIs out there.

DHL Express – uses a portal called MyDHL, which also has API capabilities. However, it uses different APIs for Freight, Express, and Global Forwarding branches, and different API approaches in various regions. Access to the web service requires a SOAP protocol, RESTful Services, or plain XML, and developers should be familiar with XML/JSON and have a basic understanding of web services. The API spec alone is 457 pages long. It is thorough, but your developer will charge you for the hours spent just reading it. Once implemented, you would need to trigger an average of 5-12 requests per shipment, starting from authentication to address validations, availability checks, and label requests.

Schenker – uses different API/EDI solutions in various regions. Most commonly, it uses a SOAP protocol with an XML format. The message itself is straightforward, provided all possible errors are handled properly. Developers need personalized access to implement the API. Depending on your location, you might be asked to implement an EDIFACT solution instead, which I will cover later.

DSV – has recently moved to their API-capable portal called MyDSV. Given that the API is quite new, it takes advantage of some of the latest and most modern approaches in the API world. Despite the complexity when authenticating and navigating their product catalogue, the approach is straightforward. Again, depending on your location, EDIFACT may be preferred.

FedEx and TNT – this can be fun. First, you need to determine whether you are using TNT or FedEx services. Although they should have been the same company for quite some years, the migration is still pending. If your contract is with TNT, you will most likely be asked to implement the TNT Express Connect API. The implementation itself is of average complexity. The downside is that this API is considered obsolete and will be shut down eventually. The FedEx API, on the other hand, is more complex and offers several options depending on the region you are based in. At Cargoson, we have implemented the FedEx Compatible API, which provides some very neat additional functionality but is available only for FedEx Compatible partners.

UPS – uses a JSON-based API and OAuth for authentication, which means there are quite a few requests you would have to trigger before you get your booking through and labels back.

Next, we have EDIFACT, used by many transport companies such as DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics, etc. It is a very old standard, and even if it might seem that you could get away with one API integration for several logistics companies, think again. The biggest downside is that it’s a file exchange-based connection, which means that you would have to generate an actual, physical file, then transmit it over FTP and literally hope that all is okay because there is very cumbersome feedback about errors and warnings.

Similar to EDIFACT is FORTRAS, a file-based connection with the same shortcomings. It is more in use in Germany and neighbouring countries. Not only is the file exchange challenging, but the file format itself is hard to read and, therefore, very time-consuming to debug errors. Some well-known companies that use it include Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss, etc.

Even after implementing all the integrations mentioned above, the question remains:

What do you do with carrier companies that lack any IT system or portal, let alone an API to accept transport orders?

The simplest workaround is to send a simple email. While this might sound straightforward, let’s delve deeper. Setting up the technical connection to your mail server is one thing, but what about contacts? Normally, different directions are handled by different contact persons, and people do change positions. Thus, you would need to build a rather comprehensive contact matrix into your ERP.

So, what are the alternatives to grappling with disparate carrier APIs and EDI protocols?

One option to consider is a multi-carrier API. Essentially, this is a service provider that has built all carrier connections, be it modern APIs, old EDIFACT- or FORTRAS-based EDI protocols or email integrations, and made them available via their own, standardized shipping API. Instead of implementing various carrier APIs and keeping them up-to-date, you can implement just one multi-carrier API standard and trigger all your transport orders through it.

But we’ve taken it even further.

Different logistics companies offer varying levels of service. Some provide a booking API, while others do not; some offer tracking capabilities, while others lack this feature. At Cargoson, we have implemented all features that fill in the gaps for each transport company.

For instance, when a carrier doesn't offer online booking, we provide a portal for that. If they're missing tracking, we add it. We've got systems for uploading proof of delivery (POD) and other documents, full-featured multi-carrier API, ETA estimates, transport price calculations, performance stats, and even transport CO2 emission figures. Basically, whatever a carrier lacks, we've built it so you don’t have to worry about IT- or service-level differences between your carriers.

See how Cargoson makes your existing carriers better

Here's a real-world example: Big players like FedEx, TNT, and DHL Express offer a pricing API. This means that when you trigger a price request from Cargoson, prices are pulled directly from the carrier's system. However, in cases where a company like DSV does not provide a pricing API, the Excel or PDF pricelist provided by DSV is uploaded to Cargoson, and the price calculation is performed within our system. We’ve got a powerful freight price upload and calculation engine for that. The same approach can be applied to all other transport companies and is also applicable to other features.

Our goal is simple: give you a consistent, high-quality experience across all carriers, even if they don't all start with the same capabilities. A de facto universal carrier API standard and multi-carrier platform in one.

If you're looking for a better way to manage your carrier integrations, Cargoson can help. Our platform provides a single, standardized transport API that connects you to all your carriers, regardless of their individual capabilities. This means you can access all your shipping services through one unified interface, without worrying about the underlying technical differences.

Want to see how it could work for your business? Let's hop on a quick call to discuss your current setup and specific integration challenges. We can walk through some real-world examples of how Cargoson has helped companies in similar cases to yours:

Schedule a free, 30-minute consultation