APIs In The Late Afternoon

After our weekly team meeting yesterday afternoon, I hopped into a cab to the far west side of manhattan to attend the Business of APIs conference. In the cab, I opened socialscope on my blackberry to check into twitter and saw this tweet from my partner Albert:

Love APIs — so excited about @foursquare's announcement http://bit.ly/1Zswju

As I sat down with Quentin Hardy to talk about APIs, I wasn't sure where the conversation would go. Fortunately Quentin is a good interviewer and we had a great chat.

We talked a bit about the foursquare api, and I mentioned that I am most excited about cool games that can get built on top of foursquare, like mob zombie.

We talked about what is a real api, and I seconded our friend Joshua Schachter's assertion that a read-only api is not an api. I believe apis should allow full read/write access and the ideal api in my mind totally replicates the web app's functionality.

That led us to Twitter naturally and I stated that the thing I want most from the Twitter api is sign up via the api. I realize that there are reasons why that hasn't happened yet, but I feel that Twitter has led the web world in providing full access to its application and sign up is a key feature that third party developers could do great things with.

Quentin seized the opportunity to pounce on the monetization question and I stated my belief that the best way to monetize apis is to "send money with the api". I talked everyone through my Business Model Jujutsu post and ended with this line from Paul Forster, CEO of Indeed:

We tried charging for our API without much success.  Then we paid developers to use it and it took off.

We also talked about "api failures". I said that there are two kinds of api failures that I've noticed. The first is when the web app itself is not very popular and therefore developers aren't compelled to build to its api. That is not an issue with the api itself. The second is when the web app itself is very popular but the api is not so much. Usually the issue in this situation is the api is too restrictive and doesn't allow developers to do enough with it. I mentioned the Etsy api, which is read only, as an example of this situation. Fortunately, Chad Dickerson of Etsy, had preceded me at the event by a few hours and talked about how Etsy is taking their api to the next level by offering both read and write.

That's about all I can remember about the talk with Quentin. It was a good one. APIs are such an important topic. I'm surprised there aren't more events about them. I'd like to thank Mashery for putting this one on. And I'll leave you with a blackberry photo I took of the view from the event yesterday evening. That alone was worth the trip to the far west side.


Reblog this post [with Zemanta]

Comments (Archived):

  1. bfeld

    API’s rule the world.

    1. David Semeria

      And I have root access Mr Bond!

      1. Mark Essel

        step 1) Build servicestep 2) force your friends to use servicestep 3) create an API so that your friends can mess with each others datastep 4) profit

        1. David Semeria

          You forgot the secret base inside the volcano…

          1. Mark Essel

            A large fraction of Victus Media’s development team is already based in Maui. How convenient 🙂

          2. ShanaC

            Does this make me a bond girl? 😉

  2. Farhan Lalji

    Wonder about speed of launching an API, do you wait to launch a read + write AP when you can launch an read only one quicker? My guess is that it took Etsy a while to do Read + write not because of strategy but because of execution, is that right?

    1. fredwilson

      i think you should go read/write right away because if you don’t, you send the wrong message

  3. terrycojones

    OK, I’m going to try *not* to break the record for the longest comment on this site. Some brief comments:APIs and UIs are similar. APIs give programs access to data, UIs do so for users.We tend to look at them in a positive light.But you can also look at them as being restrictive.You can only do what’s been anticipated, what’s allowed, what’s implemented.The last word on the data (our data!) is left in the hands of an application.APIs are not the last word in making data accessible (read or write).That’s it for now. FluidDB goes straight at the heart of the above issues. I’ll blog more fully one of these days.

    1. ShanaC

      Would love to hear about it, and trust me, that is not the longest comment on this blog.

        1. ShanaC

          Oh you’re that commentator of the infamous long comment that no one can beat. Yup. That’s a long comment.

  4. reece

    Hey Fred,Wish I could’ve been there for the discussion, and perhaps you covered this in more depth, but can you share any details on the Indeed example?I’ve read the Jujutsu post – what I’m curious about is the payment system for developers. Was it set up as an affiliate marketing payment, a one time installment, straight ca$h money?Thanks.

    1. kidmercury

      IMHO rev share is where it’s at with APIs. i think we’ll continue to see more of that as the web evolves.

      1. dlifson

        Yes, I completely agree. I hope that is what Etsy decides to do.

    2. fredwilson

      they just send their ads with their api and pay the developers a rev share

  5. Carl Rahn Griffith

    Absolutely. Plus, let’s not forget the CLI … 🙂

  6. dlifson

    Does that mean you would also support Tumblr expanding their API to the point where someone could recreate the entire Tumblr experience outside of Tumblr? While I hope that is the case, it seems they view the dashboard as a core piece of their business, or else they would have done it already.

    1. fredwilson

      great question and i talked a bit about this yesterday at the eventi believe the reason the tumblr api is less popular than twitter’s is thatit is very restrictivethat’s a business decision they have made and they really want to controlthe experience, ala applethat’s their call and we are entirely supportive of itbut it does impact the popularity of their api

      1. daryn

        Respectable and logical, even if occasionally frustrating :)It’s interesting that they chose a read/write api for posts – allowing for all sorts of great tools there, but completely blocked off any visibility to following/followers/likes, and hence the ability to anything interesting beyond actions in the silo of a single tumblelog.

  7. Mark Essel

    *update I read and commented on Jujitsu!* Interesting…it gains data/size and popularity and then you are forced to monetize more than you are paying people to use the interface. Sort of like Google’s less than free mobile navigation platform (great post by Bill Gurley).

  8. Bernardo Rodriguez

    Building a business charging for APIs seems tough (examples ?), the only reasonable way is to send ADs. If Foursquare’s APIs takes off, they will be in a great position to broker location/intention based Advertisement. That is the end game. Excellent move.

    1. fredwilson

      yes, but what is an ad?i like dick costolo’s comment from real time crunchuphttp://fredwilson.vc/post/2…

      1. Bernardo Rodriguez

        I think the challenge is less on the front-end (“where”, “when”, “how” to display). The challenge is on the “what”: how twitter makes sure that the Ad is relevant: a win-win communication between a brand/company and a user. We need to work on relevant permission-based marketing and twitter (or services on top o twitter) need to be the gate keepers. I hope quick money doesn’t get in the way of the hard and creative work that is required …

  9. Dave Pinsen

    “We tried charging for our API without much success. Then we paid developers to use it and it took off.”What would you suggest to non-venture backed entrepreneurs who can’t afford to pay people to use their products?

    1. fredwilson

      i should have explained the context of Paul’s commentthey share their revenue with their api developersthey don’t actually “pay them”sorry about that

      1. Dave Pinsen

        OK, sort of like an affiliate program then.

  10. awaldstein

    In a connected world, APIs are the connectors for building extended markets and communities. And they define the relationship between the company and its developers.

  11. LIAD

    a larger API related failure is lack of trust/communication between potential developers and the company.Will the API be there next week/will they support the same functionality/will they frequently change things thereby requiring intensive ongoing management/will they change their terms of service thereby potentially rendering an application obsolete?we encountered all these issues in the early days of the Facebook API and made us very apprehensive initially about devoting large amounts of time/money and effort to developing around/on-top of it.i think entrepreneurs are good judges about whether an API is worth investing time in all things being equal – but the black boxes above – preclude innovation on occasions for no real reason. They are all easily fixed – through simple communication and ongoing dialogue

    1. fredwilson

      yes, great point. twitter is coming to grips with this now. i think they will do it well, but it is a huge challenge to get right.

  12. Bruno Pedro

    Great post.From my experience I’d say that you should launch APIs as soon as you can and, even better, eat your own dog food by making your Web UI use your own API.APIs are the best way to expose your service features to the world. When you have an API that reflects your offer, your service will be open for anyone to adapt, mashup or use as a base for other applications.Another advantage is the speed of execution when potential partners show interest: instead of developing a specific solution you simply hand out your API documentation and let the other party integrate the features you’re offering.Speaking about read/write API and restrictiveness, I believe you should launch different API versions for different usage scenarios: a read-only API for public information, a very easy to implement read/write API for simple features and a richer API that will cover all your service features.So, to conclude: your API is, in fact, what you’re offering. Your Web UI is just a specific packaging, not the other way around.

    1. fredwilson

      good point about multiple APIs Bruno. that is best practice i think.

  13. Sebastian Wain

    On the web side many companies (i.e: Google, Facebook) use the API as a buzzword to give developers the sense of openness, but when you enter their platform it’s easy to discover a lot of flaws: for example Google has provided an API for the search engine but it’s not available anymore (now Yahoo is more open in this sense) and just recently is providing an API for “Google Sites” (when JotSpot the original company has been provided one before acquisition). In the case of Facebook they offer a “perfectly” cutted API and you can’t follow the API conference motto: “What can be done with an API is limited only by imagination…”Since our business is quasi-purely based on APIs I can share some ontopic comments: our main business model is providing APIs and frameworks (currently on the desktop side) where they aren’t and I think it’s an interesting business model. For example neither Microsoft Windows Live Mail, Windows Mail and Outlook Express provides an API but if you need to integrate things like antivirus, encryption, etc you need to rely on specific products.There many business models to explore such as:- APIs carrying Ads: The API also returns advertising to show in your web page.- Keyword Exchange Markets: APIs to sell/buy your keyword or content stock (e.g: Microsoft AdECN acquisition).- Search Engines providing more data structured APIs (like a Freebase À la carte) not just a basic query. This is very straightforward for giants like Google and is a simple step for using ontologies.- Add-ons inside the platform for webmails (like Google Labs does internally).- In the “Black Hat” side, there are opportunities extending closed sites using web scrapping, like following the MIT Solvent project. I think http://www.xoopit.com/ used some greasemonkey techniques to extend gmail and yahoo.

    1. fredwilson

      this is a great comment. you should write a blog post on this. such great insight.what is your business?

  14. RichardF

    I like your assertion of “sending money” I think it’s essential for the api to be successful.sms/text messaging companies in the UK have been offering full api’s before Twitter was born and Twitter uses their gateway provider’s api to send/receive sms.A good example of the Twitter api sending money is Twitter’s announcement today that users in the UK can now tweet pictures via MMS, if they are on the Orange network. The api that Twitter have provided Orange with is sending the carrier money because they are charging their customers when they tweet a picture.

    1. fredwilson

      right. it’s about empowering an ecosystem that makes a lot of money and making some of it yourself. it is ebay’s model, craigslist’s model, etsy’s model. i love it.

  15. daryn

    “the ideal api in my mind totally replicates the web app’s functionality.”Ideally, the web-app was written on top of the API, so any functionality in the web-app has to be exposed via the API. It’s not so much about replicating (or being able to replicate) the web-app, but to have read/write access to all of the same data and functions. There are plenty of reasons this often doesn’t get done in the real world, but it’s a good goal to keep in sight.

    1. fredwilson


  16. Joe Lazarus

    I’m not an engineer, so I don’t know how technically realistic this is, but I’ve always thought that conceptually, companies should build APIs before they build their own interface. That way, they ensure that all the APIs needed to replicate the experience are already in place. The company’s front-end engineers simply become part of their own API developer community.

    1. omichels

      Spot on, Joe – we call this “API First Development”, and is the holy grail. It is generally the path taken by people after doing it the other way once or twice and tiring of refactoring to launch the API 🙂 – more here: http://www.praxicom.com/200…Oren Michels, CEOMashery

      1. ShanaC

        Thank you for explaining that to beginners guys.

  17. hooman

    APIs are definitely key. You don’t have a true platform unless your service can be exposed via APIs.

  18. Jason Richman

    Agree with Fred & Joshua’s point re read only APIs. As a publishers, we already free our content through RSS feeds and widgets. Am struggling a bit with the value of exposing APIs around premium video content…any thoughts/examples?

  19. Oren Michels

    Fred, thanks so much for coming out. We got a ton of great feedback on your contribution, especially on your willingness to comment specifically on the disappointments as well as the successes. And, of course, we ended on eating your young and calling bullshit. All in all, a great success! Thanks again -Oren MichelsCEOMashery

    1. fredwilson

      yes, that was a great ending!

  20. shafqat

    Fred – I’d love to hear you go into more detail about the Business Model Jujutsu [sic] post. I think flipping the revenue model on it’s head is fascinating, but often easier said than done. Specifically, revenue sharing is easy-ish if your client is monetizing using CPM ads and you can calculate rev share by splitting that ad revenue. But what if the client derives value from your API, but doesn’t generate direct revenue from it? How do you “pay the client” in that situation?

    1. fredwilson

      good suggestion. i’ll work on a follow up

  21. JeremiahKane

    For APIs I always think about Craigslist as the counter factual. Has it been a mistake for them to have been so reluctant publishing their API? Does it even matter?I think there are a lot of great Craigslist never-built applications that I don’t even know I am missing.

    1. fredwilson

      craigslist is the exception that proves many rules

  22. Nick Giglia

    Fred, great post. API development is vital these days, and it seems that many of the winners are the ones who do it well.One thing the cloud computing space is struggling with is an over-proliferation of API’s given the array of businesses. What do you guys think about measures to standardize API’s or make it simpler for an end-user to call multiple API’s in a cohesive setting within their business? I’m a firm believer in the API but don’t like the thought of unnecessary complexity.

    1. fredwilson

      don’t know what i think but its an issue for sure

  23. hypermark

    Throwing a little relativity on this topic, it amazes me how many startups begin with the API as a crutch for not understanding their target user, and underlying use cases, supported workflows and optimal user experience.This is very different from saying “eat your own dog food, and build your front end on top of your APIs.”What I am saying is that while it’s great and integral in a lot of cases to create an ecosystem via open APIs, that’s a poor substitute for having a primary product vision.Axiom: “So what can you do with this API? Anything? Uh oh, then you must not have solved a specific problem.”

    1. Nick Giglia

      Excellent insight – the API has to be a way for users to augment the already-excellent experience, not a make-up call for mistakes.

  24. ShanaC

    Not that I’m hacker lady, but isn’t anyone afraid of how sharing the API can warp away the idea of content control. I mean Etsy has a failed API, but they have a very strong brand and a very strong identity. if they gave a lot away of their API, would they dilute that?

    1. fredwilson

      it’s not a failed api. it’s just an underused one. and they are putting out a read/write api soon.

  25. Jun Wong

    Maybe somewhat off topic, but i think there’s also a market for API integration with B2B applications.A great example would be those using the SAAS model for critical business activities (Analytics, CRM, Media Buying)I’m sure many people who have evaluated software / solution hit a wall where they had to pick between1) Custom application2) Pick a SAAS that gives you a product with 150% of the features, 75% of it being useful, 50% you don’t need, and 25% missing.Paying an API fee then customizing the last mile in many cases, would be the most economic alternative vs adding extra staffing / workarounds which is the current approach.

  26. Adrian Palacios

    API’s are great. But, in the scenario of an API world, doesn’t that place the digital future solely in the hands of the programmers of the world? What about the non-technical users of the Facebooks and Twitters of the future?There are so many people who don’t know JavaScript, PHP, ActionScript, etc. I feel like something even easier for non-technical users would allow for even more innovation.BTW-talk about the far west side of Manhattan!

    1. fredwilson

      i think we should all be programmers at some level.i’ve been pushing my kids middle school to replace some of their science curriculum with a mandatory programming curriculum

      1. Adrian Palacios

        i can work my way around basic html, but i would really love to know javascript or php in-depth. it’s hard to teach an old dog new tricks though.introducing students early is great. i remember having to make what amounted to a rudimentary powerpoint presentation using…hmm…visual basic?? looking back, i think it probably wasn’t as effective because it wasn’t consistent. computer class had a different meaning every year. 6th grade was typing. 7th grade was visual basic (maybe…my memory is fuzzy about that). 8th grade was oregon trail. go figure.

  27. Terry J. Leach

    Foursquare has some innovative technology behind their systems. They have the potential to have “Twitter” like popularity and with a great API.I’d like to see meetup.com adopt the same technology.

  28. Magnus Wikegård

    I can’t let this one pass.API design is like sex: make one mistake and support if for the rest of your life.This is a citation from Josh Bloch. @joshblochI read it just the other day from my twitter stream and to be able to use it already is fabulous.For more information on API design I recommend this youtube http://www.youtube.com/watc…Very insightful but kind of techie.

  29. stevenwillmott

    Great points and great comments – read only APIs definitely leave people wanting more but but even that’s a step ahead from just providing RSS. While there are certain security issues with allowing everything up to full account creation, doing it (e.g. with access restrictions to those portions of the API) opens up a whole new dimension of integration between sites. The twitter example is nice (hope they’ll indeed lead the way) but it makes even more sense for infrastructure services like box.net which could provide a lot of added value to partner sites by silently setting up different types of resources for users.Eventually almost all core functions of most sites will likely make sense by API since that’ll make it possible to write the richest apps and integrations.If there are any companies heading in this direction would be awesome to talk (http://www.3scale.net / twitter @njyx / @3scale).