Fixing what is wrong with shipping integrations
When I first began developing shipping applications a number of years ago, I was struck by all the complexity and hoops one had to jump through just to get pricing to get a package from point A to point B. Although many shipping and logistics companies had taken the time to develop public interfaces to their systems, Looking at these interfaces I wondered if they really wanted applications talking to their systems.
The first thing that struck me was all of the certifications, re-certifications, and back-and-forth provisioning e-mails and phone calls I had to go through, just so they’d let my systems talk to their systems. It was as if I was walking into a glass museum with “don’t touch” signs everywhere. Although we’re talking about big, sophisticated companies with worldwide physical and logistical resources and resource redundancy, everything sure seemed easy to break! Why were they forcing the electronic equivalent of a blood test just to get a shopping cart to rate a ground order?
Then I was struck by the interfaces themselves: lots of esoteric numeric codes, unnecessarily long message element names, dozens of internal error codes to sift through in the event something didn’t go exactly right (whether it was my fault or theirs). It wasn’t that their interfaces were incomplete, but how daunting this must have been to someone just looking to have their shopping cart track a shipment.
What I came to realize is that, for a very long time, sophisticated shipping system integration was exclusively the province of highly paid custom systems integrators and the Fortune 100 companies who could afford to hire them. This was by design, borne of the kind of closed systems thinking that predated the modern open web. Lest you think I’m joking, consider that the going rate for a reference copy of the EDI X12 transaction set (the forerunner to modern commerce XML exchanges and STILL the lingua franca if you want to do business with most of the large retailers) could cost you a cool $15,000. Frustrating, and I wasn’t the only one who felt so.
Looking around, I saw that lots of folks had crossed the same bridge, and tried to devise ways to cope with all the complexity. At the time, most carriers only published their rates in annual rate guides. Many dedicated souls transcribed these rates into rate table look-ups that could be plugged into shopping carts. But inevitably, these rate tables serve the lowest common denominators of shippers and buyers, and have some pretty significant limitations if you want to do business with anyone, anywhere, anytime. What about rate updates? Fuel surcharges? The endless exceptions? What if you wanted to ship something “dimensionally” complex like a guitar case to Umiujaq, QuÃ©bec in late December?
There was not an app for that.
Candidly, we needed one for the fulfillment side of our business and we saw an opening to develop a better way to do e-commerce shipping automation.
Shipwire APIs are designed for developers and businesses who want to worry about growing their business, not growing their knowledge of shipping zones, balloon rate rules, rural delivery fees, or northern QuÃ©bec weather patterns.
We took the interfaces we ourselves enjoyed using and rolled a set of our own APIs that we hope you find easy to use. With the Shipwire developer tools, you don’t have to sweat integrating with every carrier under the sun because we’ve taken the time to do that for you (12 carriers and counting). As we add new carriers and carrier services, these tools are automatically updated to reflect the new options available to our users. And better yet, we’ve got a ton of e-commerce integrations at the ready so you can sign up, plug in, and move on with your day, if XML is just not your thing.
Because who wants to be spending their time submitting 30 test labels to a carrier just to earn the privilege of buying a label from them?
I’d rather be traveling. I hear Umiujaq is nice this time of year.