No API? You Suck!

I have a long documented love of APIs. Ever since I started programming in the late 1970’s the idea of writing software that interacted with other software was a cool idea to me. Abstractions 30 years ago weren’t very sophisticated, but when I look back at some of the Apple II documentation in my own personal computer museum I am amazed at what you could peek and poke, even back then.

The API has been a long time staple of established companies. It has morphed around plenty – having a long run as the SDK (software development kit) as popularized by Microsoft in the 1980’s. The API in all its naked glory made a nice comeback in the 1990’s and has subsequently become firmly established as an integral part of the Internet. While occasional arguments about REST, SOAP, and XML-RPC appear, most of the time we are happy with whatever API abstraction layer we get.

Many of our Internet-based portfolio companies – such as NewsGator, FeedBurner, and Technorati – have built APIs to their services. However, the API isn’t limited to consumer companies – we’ve had great success with our friend the API at enterprise software companies like Rally Software.

Today there is no excuse if you launch a consumer web service without an API. If you do that, to you I say "you suck". Ok – it’s not trivial to scale an API up, but why not design it in from the beginning? If you wake up in a situation where your service (or API) suddenly becomes popular, you have options like Mashery that you can outsource your API to. According to Oren Michels, the CEO of Mashery, a base API package will including – in addition to the actual API code:

Documentation

Great examples of what people can do with it (I’d rather steal and modify your examples then start from scratch)

Self-provisioning (I want to play with it at 3am – don’t make me wait until you are awake to get started)

Path to success (If I’m using it a lot, don’t throttle me. Give me a way to pay you to use your API more)

I believe we are once again at the beginning of another conceptual shift. The enterprise software world has been talking about SOA’s while the parallel universe of the consumer Internet has been implementing web services and APIs galore. However, now one has really worked through broad API scale issues on an Internet-wide basis. Imagine the following scenario:

You create new a web site called "CoolNewSite". You create an API for CoolNewSite. You want to connect CoolNewSite (via the API) to the other 531,177 other web sites that have APIs. Yes – you realize that only 1,753 of them actually matter, but you’d like to be able to interoperate with all of them, no matter how large or small. So – you get to work writing 531,177 connectors between your API and all the other APIs out there. 13 years into this process, CoolNewSite becomes popular and suddenly you are overwhelmed with traffic. Your solution – start throttling the number of calls that another service can send you in a given time period so that you don’t continually fall over.

Sound – er – familiar?

There are at least two interesting businesses that come out of this problem. Mashery is one; a company we have funded called Gnip is the second. I’ve got a third one in me, but I’m going to think about it a little more and see if it’s really a business or just a feature of Gnip or Mashery.

In the mean time, this is one case where sucking less doesn’t work. Get going on your API.

Don't forget about StillSecure! We have what we call our Enterprise Integration Framework which is based on a message bus publish/subscribe mechanism for subscribing to events, interacting with the system, and extending the system. It's helped us win our biggest deals since larger enterprises always require customizations and integration with their existing infrastructure. We're working on some very interesting APIs in our Cobia framework too.

http://www.feld.com Brad Feld

Ah yes – I do love all my investments equally! Yup – StillSecure is another great API example.

http://www.zachlandes.com zachlandes

I attended a lecture at Emory University by Adam Beguelin (beguelin.com), the founder of Truveo – a video search engine which AOL bought. One of his main points was on the value of building an API. I actually wrote up the whole interview on my blog, but …
“According to Adam, another key to Truveo's success has been its API. Truveo has maintained an api in 4 popular languages and not only does that give developers the ability to work the code into their site, but it also proved invaluable when Truveo was bought by AOL. Like many startups, Truveo had a small staff of less than 10 people when it was purchased by AOL. When the company was brought under the conglomerate's wing, requests came from every part of AOL asking for the attention of the Truveo team. By having a well-documented API, Truveo is able to refer the developers to the API and spend its own group resources on technology development.”

http://web2.socialcomputingmagazine.com Dion Hinchcliffe

Great piece Brad and lots of good info about the importance of APIs these days.

You can't post ads if you're being used under an API, so how are you going to survive?

It seems to me that an API could be ruinous financially to the company that supplies it.

D

http://www.feld.com Brad Feld

Presumably you believe that additional interoperability (via the API) will either (a) drive more traffic to your site in the consumer case or (b) enhance the value of your web service in the enterprise case. In (a) you get more traffic / more user value which should enhance whatever revenue approach you are taking (ads, subscriptions) and in (b) you will increase the value to your customer as well as integration with their other systems, which has clear long term benefit for any enterprise software or SaaS sale.

Jeremiah Johnson

Don't list to Brad, you don't suck! You probably have all the confidence in the world in your devs but if you ask them to go build a public API without having a plan in mind then the result will be somewhere between silly and stupid. The mistake will be costly.

If you're building a consumer Web service, then focus delivering value and if someone realizes that they can deliver some specific value in an API then add it. Go slow building up the API or your going to burning up money. Seriously – the Amazon Web services weren't there at the beginning.

Thanks for the Mashery link – looks interesting.

http://www.feld.com Brad Feld

I (obviously) disagree with this perspective. You don't have to spend much money to create an API. Your cost will be in supporting scale, which presumably is an “opportunity” that any consumer web service wants to achieve anyway.

I don't see AWS as a relevant example (or counter example) – it's a second order outgrowth of Amazon's amazing business, not a primary driver of their original ecommerce service. Oh – and there have been plenty of ways to integrate with Amazon (whether or not you want to call them APIs) since very early on (e.g. the incredibly successful affiliate business.)

Todd Sampson

Great post Brad. I am absolutely amazed at what Oren and his crew have already pulled off with Mashery — it has become a really great service. (And, obviously, Gnip is moving quickly there as well.)

I would recommend that everyone working on developing their APIs read Jon Udell's Hacking the Noosphere talk notes — especially the parts on HPIs and “Agreements, Protocols, Traditions”:

And — blatant self-promo here — anyone looking to work on social APIs should check out the MyBlogLog's API. We are working on building what we call internally a “People DNS” system (lookup a person by ID on any service) and completely distributable profiles:

Wow, just got off a plane, and got pinged by one of my VC's telling me about this post. Thanks so much, Brad – I appreciate the kudos, and of course we're thrilled to help anyone who needs it. @david dennis – there are several ways to make money on apis – both directly (you charge for them) or indirectly (attribution links drive traffic, like compete.com, you run more auctions, like ebay, etc.). Ping me and I'm happy to chat about it.

Oren MIchels
CEO
Mashery

http://www.derekscruggs.com Derek Scruggs

@David – Depending on the business, charging for access is often a good option. SalesForce charges people to use their API and have built an entire ecosystem on it. The nice side benfit is that SalesForce.com customers expect to pay for access, so they don't balk at paying for integration between our products.

I was just thinking about Technorati's API the other day as a way to save the company. (I presume it needs saving… ) What occurred to me is that the company should be _entirely_ API. Go for the full platform upon which a million blog search apps are based. Open the index in a way that google won't.

Technorati has tried bunch of UI approaches, obviously none have been more than moderately compelling. Why not let the rest of world give it a shot? Besides, the platform is always bigger than the app.

For example Powerset is apparently launching with just an index of Wikipedia. Why? because it's really hard to index a zillion blogs. If technorati provided their index, that'd be value. They could get to market immediately.

Also, there are tons of semantic/sentiment/data type companies analyzing blogs for marketing services, seo, financial, all kinds of apps. And right now these guys are doing all their own indexing.

Don't list to Brad, you don't suck! You probably have all the confidence in the world in your devs but if you ask them to go build a public API without having a plan in mind then the result will be somewhere between silly and stupid. The mistake will be costly.

If you're building a consumer Web service, then focus delivering value and if someone realizes that they can deliver some specific value in an API then add it. Go slow building up the API or your going to burning up money. Seriously – the Amazon Web services weren't there at the beginning.

Thanks for the Mashery link – looks interesting.

David Greenstein

Don't forget about StillSecure! We have what we call our Enterprise Integration Framework which is based on a message bus publish/subscribe mechanism for subscribing to events, interacting with the system, and extending the system. It's helped us win our biggest deals since larger enterprises always require customizations and integration with their existing infrastructure. We're working on some very interesting APIs in our Cobia framework too.

Derek Scruggs

@David – Depending on the business, charging for access is often a good option. SalesForce charges people to use their API and have built an entire ecosystem on it. The nice side benfit is that SalesForce.com customers expect to pay for access, so they don't balk at paying for integration between our products.

Ah yes – I do love all my investments equally! Yup – StillSecure is another great API example.

zachlandes

I attended a lecture at Emory University by Adam Beguelin (beguelin.com), the founder of Truveo – a video search engine which AOL bought. One of his main points was on the value of building an API. I actually wrote up the whole interview on my blog, but …
"According to Adam, another key to Truveo's success has been its API. Truveo has maintained an api in 4 popular languages and not only does that give developers the ability to work the code into their site, but it also proved invaluable when Truveo was bought by AOL. Like many startups, Truveo had a small staff of less than 10 people when it was purchased by AOL. When the company was brought under the conglomerate's wing, requests came from every part of AOL asking for the attention of the Truveo team. By having a well-documented API, Truveo is able to refer the developers to the API and spend its own group resources on technology development."

David H Dennis

But what's the revenue model?

You can't post ads if you're being used under an API, so how are you going to survive?

It seems to me that an API could be ruinous financially to the company that supplies it.

D

http://intensedebate.com/people/todd_sampso5628 todd_sampso5628

Great post Brad. I am absolutely amazed at what Oren and his crew have already pulled off with Mashery — it has become a really great service. (And, obviously, Gnip is moving quickly there as well.)

I would recommend that everyone working on developing their APIs read Jon Udell's Hacking the Noosphere talk notes — especially the parts on HPIs and "Agreements, Protocols, Traditions":

And — blatant self-promo here — anyone looking to work on social APIs should check out the MyBlogLog's API. We are working on building what we call internally a "People DNS" system (lookup a person by ID on any service) and completely distributable profiles:

Presumably you believe that additional interoperability (via the API) will either (a) drive more traffic to your site in the consumer case or (b) enhance the value of your web service in the enterprise case. In (a) you get more traffic / more user value which should enhance whatever revenue approach you are taking (ads, subscriptions) and in (b) you will increase the value to your customer as well as integration with their other systems, which has clear long term benefit for any enterprise software or SaaS sale.

Oren Michels

Wow, just got off a plane, and got pinged by one of my VC's telling me about this post. Thanks so much, Brad – I appreciate the kudos, and of course we're thrilled to help anyone who needs it. @david dennis – there are several ways to make money on apis – both directly (you charge for them) or indirectly (attribution links drive traffic, like compete.com, you run more auctions, like ebay, etc.). Ping me and I'm happy to chat about it.

Oren MIchels
CEO
Mashery

http://intensedebate.com/people/bfeld bfeld

I (obviously) disagree with this perspective. You don't have to spend much money to create an API. Your cost will be in supporting scale, which presumably is an "opportunity" that any consumer web service wants to achieve anyway.

I don't see AWS as a relevant example (or counter example) – it's a second order outgrowth of Amazon's amazing business, not a primary driver of their original ecommerce service. Oh – and there have been plenty of ways to integrate with Amazon (whether or not you want to call them APIs) since very early on (e.g. the incredibly successful affiliate business.)

http://intensedebate.com/people/mike_simon15701 mike_simon15701

I was just thinking about Technorati's API the other day as a way to save the company. (I presume it needs saving… ) What occurred to me is that the company should be _entirely_ API. Go for the full platform upon which a million blog search apps are based. Open the index in a way that google won't.

Technorati has tried bunch of UI approaches, obviously none have been more than moderately compelling. Why not let the rest of world give it a shot? Besides, the platform is always bigger than the app.

For example Powerset is apparently launching with just an index of Wikipedia. Why? because it's really hard to index a zillion blogs. If technorati provided their index, that'd be value. They could get to market immediately.

Also, there are tons of semantic/sentiment/data type companies analyzing blogs for marketing services, seo, financial, all kinds of apps. And right now these guys are doing all their own indexing.