It is all the rage to use 3rd party APIs in products, such as Twitter, Facebook Connect, DirectedEdge and more. APIs provide additional data or functionality such as user-authentication or product-recommendations. They can provide your product with fast access to data and features that would otherwise take a lot of resources and time to do yourself. They are particularly useful for getting that prototype up and running.
But there are drawbacks to using 3rd party APIs. Unless you go in with open eyes, these drawbacks can cause serious problems for your product as it matures.
Lack of control
Twitter fail whale anyone? Every API you add to your product removes one more aspect you would otherwise control. Your product can only be as reliable as the least reliable API. You are also at the mercy of the API providers, who can change the rate-limits or terms of service with little or no warning. This is particularly true of free APIs. Even if you are provided with warning of changes, the changes can effectively kill your product if it is dependent on a particular characteristic of the API. Take for example Pavo.me which had to shutdown after Twitter changed their permission model or Google’s recent killing of Google Translate API.
Even worse are the undocumented and un-communicated changes to the methods and data returned. Variable names change and data is removed from APIs (even versioned ones) all the time and you only find out when your product begins to fail. This happened a month or two ago where Facebook removed a data field from the authentication data structure which in turn, broke the Facebook login to PeerIndex (where I’m Head of Product) until the developers finally isolated the cause.
Constraints to scale
Rate-limits are the bane of anyone trying to scale a product. While initially these rate limits will be fine for early prototypes, you’ll quickly hit walls whether it is the number of calls per second or the number of calls per day. While you can move from free to paid versions of the API this adds considerable cost to the product and you are still ultimately constrained in scale by what you can afford. The rate limits will bite you in the ass if you are not careful.
APIs also put scale constraints based on their reliability and performance. An API that has a return time of 1 or 2 seconds limits both the scale you can reach and your own product’s performance. In effect your product can only perform as well as the worst performing APIs.
Engineering Effort
APIs sound like a effortless method for developing but you’d be surprised at how much effort it can take to use an API. Even a well documented one. There are always quirks that are undocumented along with just plain oddities. An excellent example was found recently by a PeerIndex developer in the Facebook API where @ messages are represented two different ways within the same method.
Recommendations
So how do you get around those issues? With a bit of planning:
1. Plan the inclusion of APIs with the rate-limits in mind
Understand the rate-limits and how they are likely to effect performance as you scale. Plan how you will address rate-limits as you scale when you design in the product to include the API.
2. Understand that on-going engineering effort will be required
Know that you will need to continually have the engineering team review the 3rd party APIs to address any changes (documented or otherwise). We’ve had quite a lot of engineering time to be devoted to maintaining API related code and dealing with the undocumented quirks and oddities of APIs.
3. Use background calls where possible
When including APIs in your product, carefully consider whether they need to be realtime or whether the use of the APIs can be done in the background. Background processing allows for graceful degradation and reduces the performance hit to the user experience.
4. API must solve a real problem
Ultimately, know what problem you are solving with the API and carefully review whether you really need to use an API to solve the problem. As a product manager you’ll often be pushed to include APIs as either a) they are the current bright shiny object or b) the developers want to play with it. Although obvious, only use an API if it really does provide the best solution to a problem you need to solve.
5. Permissions matter
This is particular to when using social APIs such as Twitter and Facebook. Asking for too much access to someone’s profile does seriously effect conversion (I seen a 70% funnel loss due to asking for too much access Twitter permissions) so consider how much access you need very carefully.
6. Avoid APIs for crucial functionality
If an API is crucial to the functionality of a product, seriously consider bringing the functionality in-house. Having your product so dependent on another company is a recipe for disaster. Getting started this isn’t such a concern but as you go along try to bring the crucial functionality in-house or turn that API relation into a commercial, contract based one to establish some measure of control. Of course, sometimes bringing the API in-house is not practical but you need to make the decision of making the product’s survival dependent on an API with a clear head and if possible diversify to using multiple API providers.
APIs can be wonderful for getting a product off the ground and accelerating adoption. That should not be discounted. However, APIs can have serious a detrimental effects on a product. Product Managers must understand these effects and plan the inclusion of APIs accordingly.
What have you learnt in using 3rd party APIs?
Comments
Join the community
Sign up for free to share your thoughts