This is just a quick overview of the main differences between API and EDI. Our TMS will utilize both across the lifecycle of a shipment.
API:
We send an electronic request and get immediate responses from the carrier (this supports rating, dispatching, tracking, and imaging normally). This is a newer form of communication with the carriers and is a lot more instantaneous and controllable on both sides, which is why it’s more preferred. When we send a request we generally get a response back within 10-45 seconds.
PRO: Immediate responses and tracking updates are requested on our end every 5-15 minutes
CON: Can be a bit temperamental, even a slight change on the carrier's end can potentially take it down, but our developers are normally able to correct the issue ASAP.
EDI has been around for a while, since the early ‘60s, but it does not allow for any rating. It is normally a bit slower than API as it’s a file transfer between us and the carrier, how I think of it is similar to an email. With EDI there are different file types/messages that can be supported, for freight it’s usually the following:
- 204: Dispatch Request to the carrier
- 997: Automated Confirmation
- 990: Acknowledgment with Pickup #
- 214: Status Updates
- 210: Carrier Bill / Invoice
For instance, with dispatching, we send a message off to the carrier to request the pickup (204), then we have to wait for them to view the message and respond back to us. There are different response messages that the carrier can support though, 997, which is just a confirmation that they received our message, and 990, this is a file format that the carrier can send us the pickup number with, and if, they reject the pickup they can provide a reason as to why.
Then they’ll send us tracking updates as they see fit.
PRO: Is a lot more stable as there are set formats for each file type that can not be deviated from on either side, also one of the potential perks of EDI is that currently it’s the only way carriers can support sending over their invoices as well.
CON: Is a bit slower as we have to wait for the carrier to send over files. For tracking normally it’s not a set schedule so we have to just wait until the carrier sends us the updates.
We generally try and have the TMS overlap the two, so that we can get the pros of both and try to avoid the cons as much as possible.
That's why with dispatching we'll default to API initially since it's much faster and more likely to support receiving Pickup numbers. If we get a failure from the attempted API dispatch then we'll roll over to EDI just to make sure the dispatch gets to the carrier either way.
Then we'll attempt requesting API tracking throughout the lifecycle of the shipment so that we can try and get the status updates as fast as possible, but we'll still have EDI update the shipment if the carrier sends an update that way.