What You Need to Know About Unofficial APIs
Some APIs provide data we benefit from. Others are hooks into an ecosystem that our users find valuable, and others provide features that are difficult to build. What happens when we need access to data that users expect, but an API doesn’t exist? Maybe you’re building an automotive application that would benefit from pulling driving statistics from the user’s car, but the manufacturer’s API is private. Maybe you are a consumer with a variety of smart-home devices, but they all work with different platforms. This is where unofficial APIs come in. They fill in the gaps where official API offerings don’t exist, or don’t match your needs.
What are unofficial APIs?
An unofficial API is an API created without the express consent or input from the platform owner. Either you, or other software developers, create an interface to interact with a third-party service. The only difference is, this API isn’t sanctioned and sometimes it is explicitly not approved. These end up as REST APIs, GraphQL APIs, and sometimes even client libraries that interface with internal APIs that the provider uses. While the concept can sound nefarious, there is a long history of unofficial APIs.
Types of unofficial APIs
The least nefarious, and often most widely accept version relates more to the SDKs and clients of an API than the API itself. They can even take the form of miniature applications that interface with the service to make a feature set available that isn’t otherwise implemented. Sometimes a provider doesn’t have the resources to support every platform. In this case, the community takes it upon themselves to develop libraries and SDKs that interface with the provider’s core API. Not officially supported by the platform, but still reliable to some extent thanks to the community that builds them. These types of libraries are very popular amongst emerging languages, and can even eventually find themselves become part of the official client offering of the provider. GitHub’s Octokit is a great example of a third party, unofficial client library (node-github) that eventually became an official library.
The most common type that we think about when we hear the term “unofficial API” is the kind that takes more work. These are reverse engineered by a developer to emulate an internal API that the provider uses for their own apps. They are commonly created by intercepting traffic from the provider’s official apps, then building similar requests that mimic the actions of the official applications. This allows developers to incorporate functionality that would otherwise be unavailable. These are often difficult to set up or use, because they can sometimes rely on cookie signing and a variety of workarounds to make the authentication process work. This style of unofficial API can sometimes draw negative attention from the provider, as they may not intend for their private endpoints to be used. Either because they want control over the data, or because the service makes certain assumptions about the use of the internal, private API and has not yet developed a strategy to adequately manage external users.
Finally, there are a variety of manually-built APIs for data sources that otherwise do not exist. These are often created as educational tools or for demos. Two examples are the Star Wars API and the Pokémon API. These are read-only data APIs that exist without explicit consent of their intellectual property owners. Similar instances of knowledge-based APIs exist across domains, and act as unofficial APIs for niche topics.
How unofficial APIs work
Unofficial APIs work mostly like any other API. They are often REST or GraphQL, and except for authentication they work the same way you would expect. By designing the APIs to match formats familiar to many developers, the adoption and management is daunting.
Authentication is complicated by these APIs existing outside the original provider’s ecosystem. Instead of an API key or approved method to authenticate, unofficial APIs sometimes expect users to obtain their own access credentials. Sometimes even going so far as to ask users to provide their username and password. The obvious security risks that happen in these situations make APIs like this harder to trust. As with any dependency, it is important to take the authentication requirements into account before integrating an unofficial API into your application.
Pitfalls of unofficial APIs
While unofficial APIs can offer direct access to a resource that was otherwise unavailable, it is important to be aware of the downsides. Most importantly, unofficial APIs can stop functioning at any time. Unlike a normal API downtime or outage, when an unofficial API is cut off by the provider is could take days or weeks for the provider to find a new workaround. In some cases, the API will be finished for good.
Another potential concern relates to platforms. Recently, Apple removed a third-party Tesla Watch app for using a third-party API. The application has since been reinstated (as of this writing), but as platforms focus more on security and privacy—especially in markets like fintech and automotive—it may become a larger liability to use an unofficial API.
As mentioned above, security can be more of a gray area with unofficial third party APIs. If the solution is open source, or doesn’t rely on third-party code at all, you can perform a more official security audit. If, however, the API requires you to go through a middle-man or proxy to access the desired data you now need to consider what kinds of data you are sharing and how any compliance requirements within your organization will affect the decision.
Can unofficial APIs help your application?
As data becomes more valuable, our applications become more connected to other applications. In a perfect world, every service we need to interface with would have an open and affordable API solution. Unfortunately, that isn’t always the case. By taking advantage of existing unofficial APIs, or building your own, you can provide additional value to your users. By connecting them with their profiles on other services, or by pulling in useful resources and features that compliment your own offerings.
Just like any third-party API or dependency, you need to be vigilant about protecting your application and keeping it resilient. Fortunately, you can use many of the same techniques you would use for integrating with any other API. At Bearer, we’re all about keeping you informed about how your application uses third-party APIs. Through tracking, performance monitoring, and active solutions to common API problems we can keep your application protected. Give Bearer a try today and learn more about how we can protect your apps.