If you’re working with software engineers, chances are you’ve heard someone blather on about APIs. But these days, it’s not just developers—you’ve got partnership marketers, leaders in biz dev and CEOs asking about them and trying to figure out if they’re good for business. Before you get stuck in a meeting or a technical conversation thinking it’s all over your head, think again.
What Non-Engineers Need to Know About APIs
Ask most developers what an API is and you’ll probably get lost in a sea of acronyms, but fundamentally they are quite simple. An Application Program Interface is a contract for data interaction. It lets applications ask specific questions, and provides answers when it has them. It also allows certain data to be submitted, which it can store for others to question.
To use an overly simplified and anthropomorphised example, think of the Facebook mobile app. When a user loads it up on their device, the mobile application will ask the Facebook API:
Hey Facebook, get the 20 latest items from this user's news feed.
If the device is sending a good authentication token (i.e. the user is logged in), then the server will respond with the information it has:
Here you go: the latest 20 items, with related data on the user, feed item, and some other relevant stuff!
To think about sending the data, the example might be:
Hey Facebook, the user wants to post this status. The message is "Hey look at this awesome cat picture" and they also included an image "kitty.jpg".
The server will accept the status and respond with a success code, or fail and return an error.
Data requests and responses are defined in some pre-agreed format, which is the contract we talked about earlier. This contract might be written down on your website, or as word of mouth between developers who sit next to each other, but at some point a contract is made. So long as change is handled cautiously, any number of permitted mobile/desktop applications, websites, or other APIs can continue to integrate with yours.
Why Everyone & Their Dog Wants an API
For the last decade, APIs have gotten increasingly popular due to the rise of smartphones, and the Internet of Things adding things like smart watches and smart toasters has only sped things up. Any tech startup you can think of will have them. Companies like Lyft, Instagram, and Postmates built them for their own web/mobile applications, then opened it up to other developers to make a bunch of money.
Order a Lyft from your Apple Watch thanks to Lyft's API.
Sell an item on your e-commerce store and have Postmates deliver it via the Postmates'.
However, building APIs is not just some trend amongst the cool unicorn startups—it’s a common way of doing business. The big banks are sharing data with them, hobbyists offer every piece of Pokémon data you could imagine, the US government offers data on traffic violations, you name it!
Things that used to involve downloading a giant CSV file are more commonly offered up via an interactive API these days. Complicated tasks like facial recognition or text-to-speech that previously would have involved writing a lot of code or hiring experts can now be outsourced to another company, and you can just pay to use them. In the same way, maybe your company can open up certain subsets of its data, or its own functionality, and maybe you can monetize that as a secondary income source.
Strava built theirs to handle us cyclist nerds who wanted to track our rides, and ended up making a new income stream: Strava Metro. They anonymize and aggregate data, then offer insight into the roads with the most accidents, the most bike traffic, and wait times at intersections to cities looking to become more bike friendly.
Building your own can be a huge benefit to your own company for building your own applications, but it can also be a great source of primary or secondary income. As you open up to other companies and maybe even the general public, you can start to see integrations you’d have never even considered. Who knows, it might even evolve your business, and give you ideas for new products and features.
About the Author
Phil Sturgeon has been building APIs professionally since 2010. He’s worked as a freelancer, consultant, and CTO for several technology startups. He published Build APIs You Don’t Hate, and the Slack channel that grew from it has become home to the largest API chat group on the internet. Phil is currently working as a consultant at WeWork.