If your job is to develop a connector from your business systems to a multi-carrier API, there are some important considerations you should keep in mind.  

It’s a multi-carrier world. The days of picking a carrier or two to handle all your transportation needs are long gone. Customers are demanding more delivery options. The driver shortage and carrier capacity crunch are creating reliability issues. As a result, costs are only going up with no end in sight. To effectively manage costs and delivery, you need to integrate with carriers. Integrating with carrier APIs is a non-trivial exercise and most IT departments are already in project overload mode. That is why multi-carrier APIs that broker messages to disparate carriers are so attractive: one connector links you to all your carriers.

But thinking that a single API connector will solve all of your transportation logistics problems is like thinking a dictionary will enable you to write a sonnet. There are lots of gotchas waiting in the weeds for unsuspecting programmers.

Beware: The Rate Wait

Say that 10 times fast. Speaking of speed, you will need it if you expect to support shopping cart shipping cost estimations.  A multi-carrier API that relies on other carrier APIs is only as fast as each carrier’s API. Instead of milliseconds, some carrier APIs process requests in many seconds.  On some days or certain times of the day (like at the end when shipping volumes spike), it’s even slower. Moreover, some carriers will deny service to your API requests if they exceed a sometimes-unknown maximum limit.

Make sure the multi-carrier API you select supports alternatives to carrier API based rating. Look for rate management tools to import discounted rate structures for parcel, freight, and mail services. Global shippers need to consider international rating capabilities and postal codes. 3PLs and brokers will need utilities to manage buy and sell rates.

OK. I Got a Label Image. Now What?

The Internet of Things (IoT) is more than just a buzz phrase. OK it is that but it also describes technology that is essential for supporting production-level logistics processes.  If you ship a lot of parcels, your cloud-based multi-carrier API will need to securely integrate in real time with high-speed thermal label printers.  Your multi-carrier API should have an IoT component that will enable your programmers to plug-and-play with local high-speed printers, scales, and material handling devices.  Make sure it works with all the major browsers.

Also, watch out for the label and document formats that multi-carrier APIs return. PDFs and other images could significantly slow down thermal label printer performance.  Your multi-carrier API should return thermal label printer instructions in the form of Zebra Programming Language (ZPL) code. That will give you the speed and consistency you will need across all carriers. The ability to reprint and add reference text to labels is also important.

Look for Breadth of Carrier Network Support

Words of advice: get your logistics department involved early to make a list of all the carrier services they will need to support transportation functions across the enterprise. Consider parcel and freight rating, special services, accessorials, shipping, tracking, and return functions. Increasingly your customers want delivery options and the carriers are responding, including freight carriers who are offering new white-glove home delivery services. These should be available in your multi-carrier API.

In real estate, it is location, location, location.  In IT, it is security, security, security.  Make sure your multi-carrier API provider has taken precautions to properly secure their environment and your data. Look at where it is hosted, whether there are backup procedures in place and whether penetration testing has been implemented. Obviously SLAs are a concern.

Supplement API Integration with Robust, Multi-functional Apps

As a programmer, you know instinctively what happens with IT projects. They start out with a simple requirement and then scope creep sets in. You can expect the same will happen with multi-carrier API integration.  Chances are you will be asked to automate other transportation workflows across the enterprise that don’t lend themselves to easy API integration.

A robust multi-carrier TMS should support both API access and the ability to roll out apps that will satisfy complex user requirements including:

• Parcel vs. Freight: Processing freight is different than processing parcels. But they are becoming more alike as freight carriers move toward space-based (dimensional) rating and last-mile delivery. You may need to use a cartonization and palletization app to determine dimensions and to rate shop multi-pack bundles vs. freight rates.
• Hospital Lanes: There is no such thing as a perfect world, and if there were you wouldn’t find it in a fulfillment center. There are always exceptions (re-weighs, SWOG, multi-pack CODs, last minute shipments, returns, etc.). As a programmer you could spend a lot of time trying to account for them or simply deploy a TMS app that uses the same API you are integrating.
• International Documentation: Your international shipments need more than a label or bill of lading to get across borders. You need to classify goods and make sure customs documents, including electronic ACE filings, are matched up with the right shipments along with other shipping documents.  It may be best to handle these transactions with a pre-built app.
• Dangerous Goods: In the same way regulatory requirements related to cross-border shipments are difficult for a programmer to navigate, the mandates around hazmat compliance are even more arcane.  And the sanctions for getting them wrong are equally severe.  You may want to use the TMS apps that have been developed by experts with years of experience.

Will Your API Connector Be Cast in Concrete?

eCommerce is the Great Disruptor of our time. Traditional industry categories are blurring.  Retailers and e-tailers are beginning to look like couriers, freight carriers like parcel delivery services, and traditional carriers like 3PLs. Gig economy civilians are delivering packages. Change is a constant.

In this environment, you can’t afford to redevelop your multi-carrier API interface every time a carrier changes its service portfolio or new carriers are added. Expect it.  So beware of tightly coupled WSDLs and other proprietary APIs. You will want to avoid having to redevelop and recompile your API connector if carrier rates and services change. Remember why you wanted to write to a multi-carrier API: simplicity and resource constraints.  So put a little more time in up front and write to a loosely coupled REST end point or even a plain old XML (POX).

 Conclusion: Do Your Homework

As with all IT projects, defining requirements is the first step. Find out all of the services and apps your logistics managers need to support transportation requirements across the enterprise, including purchasing, order entry, eCommerce, customer service, fulfillment, and returns.  Then make sure the multi-carrier API you select will support your organization now and in the future.

—

For more than 25 years, Bob Malley has helped thousands of businesses reduce transportation costs and streamline fulfillment with parcel TMS. As CEO of Pierbridge, Bob has built a global organization that developed Transtream, an enterprise class parcel TMS platform.  Pierbridge and its technology partners, Logistyx and Pitney Bowes, have achieved FedEx Compatible Platinum certification, based on shipping volume throughput, support of FedEx’s most current service offerings, and other key certification criteria.  Pierbridge has also earned UPS ConnectShip Platinum certification status.  Now part of the WiseTech Global group, Pierbridge will expand and drive deeper into global e-commerce fulfillment.