Not all Enterprise Shipping APIs are created equal. Here’s what you need to consider when evaluating how to augment your enterprise systems with multi-carrier shipping capabilities.
There has been an explosion in Enterprise Shipping APIs. But how many of them will provide you with the breadth and depth of capabilities you need for production-level deployment across your enterprise?
Here are the top 10 things developers and IT personnel should consider when evaluating Enterprise Shipping APIs.
1. Scope of Capabilities
Look for key functions that will support a broad range of logistics and transportation capabilities needed to augment your enterprise systems across your organization, from order entry through to fulfillment and reconciliation:
- Routing, rating, and rate shopping across all mail, parcel, and freight modes
- Expected time of delivery
- Address and residential status verification
- Restricted party screening
- Cartonization and palletization (watch out for those DIMs!)
- Integration with scales, thermal label printers, and other devices from the cloud
- Domestic and international shipping
- Regulatory compliance for hazmat and customs
- Pickup and alternate delivery requests (ex: FedEx stores)
- Tracking and tracing
- Returns processing
2. Enterprise Administration
For larger enterprises, be sure you understand the effort necessary to import users and locations, and configure carriers, business rules, routing rules, and preferences. Not all locations, suppliers, or user groups use the same transportation services in the same way.
3. Apps and Widgets
Chances are that even if you want to build an interface to an API to augment your enterprise system, there are still some battle-tested apps you would rather not have to build and support. Load consolidation, track and trace, returns, international and hazardous material compliance, mail management, and office shipping are just a few that come to mind. A TMS platform (cloud or on premise) should be able to supplement your Enterprise Shipping API integration with production-ready apps. UI widgets should plug right into your website pages to automate customer self-help tasks such as returns, pickup requests, and tracking.
4. Parcel Carrier Support
Many parcel Enterprise Shipping APIs are a mile wide but an inch deep. They claim to support certain carriers, but in reality they don’t support all the services a parcel carrier offers, including special services and contract services such as cross-border consolidation or alternate location delivery services. Logistics managers will find this out too late. Most importantly, check to see if your API provider is licensed and certified to offer UPS and FedEx services within their platform for both on-premise components for high volume requirements and for web services. If they are not, you risk losing support for these services when you least expect it.
5. Freight Carrier Support
The “parcelization of freight” is well underway. Parcel and freight modes are converging to support last-mile delivery. The lines between what is parcel and what is LTL (now nicknamed LTP - “Larger than Parcel”) are blurring. You need to be ready. Unfortunately most freight Enterprise Shipping APIs are not robust enough to support the kind of throughput required by parcel Enterprise Shipping APIs (waiting 10 seconds for a freight API rate is not uncommon). And most parcel Enterprise Shipping APIs do not support freight processing beyond simple bill of lading printing.
6. Internet of Things
Yeah, we’re tired of the hype too, but being able to connect to local data sources and devices from the cloud is a necessity for anyone trying to support high-production environments. Cloud-based APIs really do need to support IoT technology in order to connect in real time to scales, scanners, thermal label printers, and other material handling devices. This should be part of the API message set.
For companies who ship a lot of parcels, or need to rate shop lots of LTL carriers, every millisecond counts. API “aggregators” typically miss the boat here. They rely on carrier APIs, and, as noted above, many of the freight carrier APIs are too slow for production-level use. Moreover, overuse of their APIs can result in a “denial of service” and then you are done. Your Enterprise Shipping API performance will need to be able to scale to support millisecond response times in shopping carts and fulfillment.
Related to performance, how your TMS system is architected will determine your deployment strategy: on premise (for max speed), cloud, or a hybrid of both. Look for high availability during those high volume periods and redundancy.
With so many hackers on the loose, it is more important than ever to ensure that APIs are protected against unauthorized intruders. Check to see if your API provider has been audited and penetration tested by a competent third party and is ISO certified. If you are using apps in conjunction with your API, look for single sign-on (SSO) capabilities. And watch out for unsecured browser plug-ins, a faux IoT technology and a hacker’s dream.
Make sure your parcel TMS supports local units of measure, time zones, currency, and those special characters required for some languages. Your business may not be international yet, but you want to be ready when it is.
API technology is deceptively simple. Pay close attention to the details because, as every developer knows, that’s where the devil lives. At the end of the day, you need to be able to rely on your Enterprise Shipping API provider for both business and technical support. While it is easy to publish an API, you need the benefit of industry knowledge, use cases, and experience to ensure you have everything you need to support true enterprise API development.