This post is part of Lob’s series of interviews with developers, technical strategists, and business leaders on innovation, solving problems, and building tools for the fast-evolving world of operational APIs. Each post shares actionable tips to apply to your own projects, products, marketing campaigns, and logistical operations. Sign up for our blog newsletter and we’ll deliver these insights directly to your inbox!
In the trenches of the API economy, you're either setting the curve or falling behind. We spoke to Laura Wu, CEO at Shippo, about her experiences launching a company and keeping pace with the evolution and commoditization of APIs.
Laura: My co-founder Simon and I decided to start Shippo three years ago. We were building our own little e-commerce store using Shopify and Stripe for payments. These APIs made it very easy for us to have a user-friendly experience when it came to sales. We realized, though, that there wasn’t an easy way to easily pinpoint our most cost-effective shipping options. We had to make this comparison offline or rely on technology provided by shipping carriers, which was not transparent or easy to integrate with our storefront at all. Working with shipping carriers was a completely different experience than Stripe.
That was the first time we realized that access to shipping technology is really hard. Shipping companies aren’t tech companies, so the technology they’re offering isn’t up to date. They’re not making the access to that technology simple. And, it’s not their focus. Their focus is on providing the best shipping options, not on building the best shipping technology.
The idea for Shippo came from our personal experience for this major need in the market.
Laura: I’m passionate about APIs because they help businesses—and people—succeed. With this technology, businesses can automate necessary processes and devote their resources to what they’re good at. Companies like Stripe and Twilio have created a movement in which developers are seeking out APIs to solve problems. Meanwhile, this new technology is becoming universally accessible.
APIs enable innovation in established industries in which there’s a need for speed and agility but solutions aren’t likely to emerge from the inside. Sometimes, it takes an outsider’s perspective—like ours—to build a solution to a widespread problem.
At their heart, what APIs do is simplify unnecessary complexities.
Laura: For one, ecommerce is growing at a crazy rate and will continue growing. Brick and mortar locations are becoming secondary places for people to shop.
It also means that every single eCommerce store needs to ship, because people don't walk to a location anymore. Customers expect the items that they find online to arrive at their doorstep within a reasonable timeframe. The expectations around those timeframes have also changed. Customers expect items to arrive faster than ever. They know about on demand delivery options and same day delivery options. People want some sort of predictability around when their items are going to arrive, they want to be kept updated, they want constant communication and touch points, and then most importantly, they would like to pay as little as possible for all that added convenience and speed.
APIs of the future will do two things:
(1) They’ll evolve to meet users’ preferences, over time
(2) They’ll unite markets that are otherwise fragmented
There are all these new options that we've not heard about before that are just getting started, and I do think that they will become universal and that people will expect every single eCommerce store to offer these options to the buyers. We're looking at a market that is becoming more and more fragmented on the shipping side, more people are expecting different kinds of shipping options that weren't available even three years before.
We offer scale as a service. When you connect to our API, you're able to connect to scale in that we have tens of thousands of different customers shipping packages every single day. Even if your company is not the size of Amazon, you suddenly get access to a scale of shipments that is significantly bigger than what you currently have. We're able to provide you with data insights that we gather across all the packages that we ship, and we're able to provide you with a network of shipping providers that you wouldn't be able to integrate by yourself otherwise.
Our data insights and the rate at which we introduce new features are driven by our customers’ needs. Our customers are looking for further improvements or further insights around trends at times, so instead of looking at predictive transit times that the shipping providers return, they want to know the actual transit times that we can show them through the historic tracking data that we have in our system. They want recommendations around whether or not to add another shipping provider, which shipping provider makes most sense for them, whether or not to add another box size to the different packaging that they're already offering.
You need to ensure that your customers have the development resources necessary for a successful outcome. You need to make sure that integrating your API is as easy as possible and that people always have the right points of contacts, that people are not being left alone. A ‘plug-and-play’ scenario for API companies is often unlikely.
One major challenge that we experienced was on the technology side. For instance, at one point, our company aggregated many different other APIs. But end users don’t necessarily see or care about the dependencies that we have. Downtime resulted in a poor user experience.
If an upstream API is down and our API is therefore down or partially down as well, that's something that gets our customers angry. They trust our solution and they don't care what other companies we're dependent on. In order to mitigate that problem, we have built a layer of abstraction that lives on our own servers that we call our own internal rating engine, that makes sure that everything, that we control the entire technology experience, and that we're not dependent on anyone else's technologies anymore.
When you call our API to retrieve, for example, a USPS label, we don't need to rely on the USPS technology to get that label anymore. We call, everything lives on our own servers. We return the right shipping rates from our own servers without ever having to communicate with USPS, and return the label from our own servers as well. The USPS technology can be completely dead, and we can still give you USPS labels.
Laura: I think best practice around API to companies or technology companies in general is having a very transparent status report. We have a status page, most other API companies have a status page as well, where developers can always see if the API is down or if it's up. Then, you should be able to have an understanding of how much of the technology they're controlling themselves.
The best API companies are avoiding becoming commodities. That's the challenge there, making sure that your product is truly adding more value to the customers than someone who has a very similar API. Given that APIs are something that live in the background that you integrate in the background, it's easy to swap them out against just any other API that provides a similar service. Making sure that your technology is truly better in a very tangible and measurable way, and that you're not becoming a commodity.
Laura: APIs aren't vitamins for businesses. It's important to have a clear strategy behind your technology implementations and a partner that can support and help implement those visions.
APIs like those built by Shippo and Lob help businesses automate necessary processes and focus on differentiation. However, without thought and careful implementation, it simply becomes about stacking commodities. When choosing an API partner, you should look for differentiated companies that carefully build their product so it adds real value to yours.
