In just a few short years, the number of 3rd-party APIs on the web has exploded. Everywhere you look, it seems like just about every important service and app these days has an API available for developers to tinker with.
But can you trust them? How do you know that an API provider is serious about their supporting their developers and won't change things on a moment's notice?
I've spent the vast majority of my career - almost 25 years now - building and promoting developer platforms. I even had my own software company for a while where I was the consumer for an API platform that I myself had helped build, so I've been on both sides.
In this post, I've put together a series of questions that you can ask yourself before you fully commit to an API to try and gauge how much you can trust it - and the provider. Now, I'm going to invoke professional courtesy here and not call out any third parties by name since I work for Google, but I will use some instances from my personal experience to show what I feel are good examples of API stewardship.
An API that doesn't directly support a provider's revenue or strategic goals can be more easily curtailed or changed by the provider if it begins to go in a direction that they don't like.
1. Does the API directly support the provider's revenue stream or strategic product goals?
This criteria is important, but not always easy to assess. Let's take a few Google examples for illustration (again, full disclosure here - I work for Google). The Drive API directly supports Google's main goal for Drive - that is, to increase the adoption of Drive. To that end, the Drive API gives pretty deep and wide access to the service, and makes it easy for developers to integrate directly into the Drive UI itself. Google even calls out apps that use Drive in the Chrome Web Store.
Another good example is Apps Script, the API for Google Docs. Here again, the main motivation for Apps Script is to enable developers to create features that Docs itself doesn't yet provide or address scenarios that are too niche for Google to spend much time on, thereby increasing the appeal and adoption of Google Docs.
In both of these cases, the API exists to further a strategic goal - the adoption of the product in question. As such, developers that adopt the API help further the strategic goal, ensuring that the interests of both the developer and the provider are aligned.
An API that doesn't directly support a provider's revenue or strategic goals can be more easily curtailed or changed by the provider if it begins to go in a direction that they don't like.
2. Does the API give you access to "the good stuff"?
This is also a pretty good indicator of how much you can trust the API. If an API only provides superficial access to data or capabilities that really aren't that valuable, then you have to wonder about the intentions of the provider or what they might do in the future.
APIs that give rich, deep access to the important features of a service or product indicate that the API provider cares enough to think through how the API will be used and to devote engineering resources to the development and maintenance of the API.
An API that only gives you the ability to develop ancillary, convenience features - what I call a "vanity API" - is a pretty good signal that the provider doesn't have a big commitment to the API or to its developers. It's a lot easier to close off an API that doesn't have deep hooks into the underlying service than it is to change one that's going to affect a lot of customers down the line.
Even if the provider doesn't close off the API, the risk is that you're just serving as a free R&D resource for them. If you make a convenience feature that's popular, there's nothing stopping them from just copying it and rolling it into their core service. Caveat developer.
3. Is the API being actively developed, with a vibrant community?
An API that is receiving regular updates and has a large, active community on Stackoverflow or other forums is generally going to be more trustworthy than one that doesn't.
Regular updates that include new features, samples, and bug fixes demonstrate responsiveness and attention from the provider, and an active community shows that there's a well-worn path where you can get support from sources other than the API provider.
4. Are you able to make money using the API, without the provider interfering?
This one is huge. If the API provider puts unnecessary or onerous restrictions on how you're able to charge for your product, then that's a big red flag on how much you can trust the API.
QuarkXPress sold for $895 at retail (back in early 1990s dollars). I kid you not, we actually had a plug-in developer who charged $75,000 for their product (now, obviously, this was not a consumer-facing thing. In this case the product was for large Atex pre-press systems). Did we care? Hell no. We thought it was awesome that someone was able to sustain a business like that on top of our platform. Of course, most of our developers charged a lot less, but the fact that someone was charging 100x our product's price was not a problem for us.
Now, you might have to upgrade your API usage to a paid subscription in order to make your own product charge-worthy, but that's actually a good thing - a provider that charges for enhanced API service is entering into a contract with you, which in turn makes it harder to change or discontinue that API.
5. Does the API Provider itself use its own API for shipping features?
This criteria is a bit asymmetric - if they don't use their own API for their features, that's not necessarily a bad thing. But if they do use it for their own features, that's a powerful indicator that they've got a big incentive to invest in the API.
When I worked on Dreamweaver and then later on Microsoft Visual Studio, one of the things we were most proud of was the fact that we used our own API to deliver new features in the core product. It sent a strong message to our ecosystems that we cared enough about our API that we used it ourselves and considered it solid enough to deliver core features to our users.
6. Does the API Provider actively promote its developers?
Again, this one isn't necessarily a very strong indicator, but it helps to know that if you build a product that's based on an API that the provider will be there to help you promote it.
On the other hand, If a provider is squeamish about promoting its developers, that can be a bad sign. Ideally, you want to have a company that cares enough about the success of its API that it isn't afraid to call out developers who build great products on top of their platform.
Summary
Third-party APIs can be a great way to leverage the features of services that you don't want to have to build yourself, allowing you to focus on the value proposition of your product. Relying on them, however, introduces a certain level of risk. Hopefully, by asking yourself the questions that I've posed here in the post, you can minimize that risk and build a successful product.
In short, look for:
- APIs where your interests and the provider's are aligned
- APIs that give you access to the valuable, interesting stuff
- Active development on the API with a great, supportive community
- The ability to make money without draconian interference from the provider
- A provider that uses their own API for new features
- A provider that isn't afraid to promote great developers and apps
Now, to be clear, the answers to these questions aren't foolproof, iron-clad guarantees that you can trust an API to be there over the long haul or that the provider won't change things (or rip out the rug from underneath you). But if you think about these issues up front, they can help you avoid relying on API services that one day suddenly change their mind about your value to them as a developer.
