Four Mistakes SaaS Companies Make with their APIs

To all Software as a Service Companies,

Thank you for all your great ideas and for fueling the growth of cloud-based services globally. There have never been as many options for companies to choose best of breed solutions for their business processes! However, as an integrator that helps these companies link their apps for more efficiency, I must tell you that some of you are making mistakes regarding your API offerings. If you want to make your app more popular, more accessible, and more capable of catalyzing efficiency, read on! 

1. Not offering an API

What? Why are you offering software as a service, and then not giving it a way to reach other apps? Crafting an isolationist application "foreign policy" is not a good idea in a world of apps that is only becoming MORE interconnected, and that is just a benefit that is too important to dismiss. What's that you say?  "Our database structure is proprietary and opening an API would expose it".  Please. No database structure is that proprietary! All CRMs have things in common. All accounting apps, ecommerce, cloud storage apps have things in common. Shall I go on? The fact is, your service is probably not that different from others on the market at the database level. Companies imitate each other all the time. Maybe you imitated someone else? Refuse it or deny it, it's how you present your service that is the differentiator, and the failure to present an API is a big liability.

But, you say, "APIs represent an additional security risk"! Well, so do login screens and people who share passwords. The benefits of making your application interoperable and sticky through API integration far outweigh the security risks. Plus, no one says you have to make sensitive data API accessible! Examples abound - many of the leading payment provider services offer APIs that do not expose cardholder data or sensitive personally identifiable information.

Still not convinced? Perhaps a little John Donne will do the trick:

No man is an island,
Entire of itself,
Every man is a piece of the continent,
A part of the main.
If a clod be washed away by the sea,
Europe is the less.
As well as if a promontory were.
As well as if a manor of thy friend's
Or of thine own were:
Any man's death diminishes me,
Because I am involved in mankind,
And therefore never send to know for whom the bell tolls; 
It tolls for thee. 

John Donne

The bell tolls, so let's move on.

2. Not offering an Open API

Do you restrict API access to only "approved" developers? I'm not talking about building an app here, which I agree justifies a structured approval process. What I am talking about is opening access to the API so any developer can experiment with it.  Citizen developers are often the best at raising issues and suggesting enhancements. There is a larger population of curious developers than the subset of those developers who go on to build applications with your API. Why restrict your offering to the latter? Take advantage of the demographics and use numbers to your advantage!  Also, do you really want to commit resources to subjecting all developers to an approval process just to try out an API? The serious ones will eventually come forward anyway when they want to build an app or to partner with you.

And, please, don't give me the "but users will use the API to port data out of my service!" excuse. That's a bunker mentality if I ever heard one. If you're not offering users a compelling reason to stay with your service to begin with, playing mind-games with API access is not going to help them stay either - they'll find a way to leave regardless. Also, as someone who has helped companies bulk transfer data both in and out of various applications many times (sometimes via API, sometimes not), I have to tell you that transactional APIs are not terribly efficient at moving bulk data around anyway. 

Oh, and if you're worried about increased transaction volume, just put in rate limits (many SaaS companies have already figured this out, by the way) but leave the gates open to those who want to experiment. Developers love to experiment, and if they like how easy it is to use your API, they might even talk your service up!

3. API Documentation that Sucks

So, great, if you made it this far, you probably actually offer an API!  It better have a good instruction manual. Documentation is essential and if you want people to actually use your API.  Oh, and be careful about listening to that old API development team fantasy that your "API is self-documenting". Hogwash! No API on earth is self-documenting. Sometimes people think that having a RESTful API means that it's clear how it works. I've seen SOAP APIs that are wonderfully documented and RESTful ones that are as clear as eroded Mayan heiroglyphics. Bottom line, you need to invest some thought around making your API easy to use and including instructions with examples.

And by the way, I've written a whole other article on this - check it out! 

4. Creating terms and conditions and contradict the use of the API

Do you think anyone really reads your service's terms and conditions? Hardly anyone does, and who can blame them?  I have grudgingly started paying more attention to them because of one particularly doltish bit of verbiage that recently came to my attention. While scoping out an integration to gather some analytics out of a certain ecommerce marketplace platform, I was pleased to discover a fairly robust API. I then skimmed the API/developer terms and conditions and found a section that went on to prohibit the use of the API for any data reporting purposes. Just. Speechless. That was the whole point of the project. So much for that idea...

Now, most companies will have reasonable controls against misusing data (spam, building marketing databases without protecting personal info, etc.). Fine and dandy. But I've been surprised at how shockingly idiotic some restrictions are. Are you letting your legal team compete in a paradox composition contest? Do they consult your technologists and marketers? This kind of dissonance suggests an organization with some pretty big communication flaws. When you offer an API, give developers the freedom to use the data how they like, without putting use-case restrictions on it. And developers - read those terms and conditions, paying close attention to verbiage around data-use (I suggest right before bedtime).

Conclusion

APIs are the gateway to interoperability. They make your service offering more compelling because it can be used in myriad scenarios and extend business processes across different applications. Once your customers have integrations in place, they'll love the efficiency and they won't want to leave! Build a following of developer advocates by offering an API, making it open and easy to use. 

Thanks for listening and keep up the (mostly) good work!

Sincerely,

Derek Gau
President
Apigrate LLC