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.
API’s rule the world.
And I have root access Mr Bond!
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
You forgot the secret base inside the volcano…
A large fraction of Victus Media’s development team is already based in Maui. How convenient 🙂
Does this make me a bond girl? 😉
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?
i think you should go read/write right away because if you don’t, you send the wrong message
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.
Would love to hear about it, and trust me, that is not the longest comment on this blog.
See the first comment on this post http://www.avc.com/a_vc/200…For more on FluidDB, I suggest the high-level description (with links to API) at http://doc.fluidinfo.com/fl… and some of the blog posts (particularly the early ones) at http://blogs.fluidinfo.com/…Thanks for your interest! I’m happy to say more in email, and/or in #fluiddb on irc.freenode.net
Oh you’re that commentator of the infamous long comment that no one can beat. Yup. That’s a long comment.
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.
IMHO rev share is where it’s at with APIs. i think we’ll continue to see more of that as the web evolves.
Yes, I completely agree. I hope that is what Etsy decides to do.
they just send their ads with their api and pay the developers a rev share
Absolutely. Plus, let’s not forget the CLI … 🙂
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.
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
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.
*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).
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.
yes, but what is an ad?i like dick costolo’s comment from real time crunchuphttp://fredwilson.vc/post/2…
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 …
“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?
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
OK, sort of like an affiliate program then.
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.
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
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.
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.
good point about multiple APIs Bruno. that is best practice i think.
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.
this is a great comment. you should write a blog post on this. such great insight.what is your business?
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.
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.
“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.
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.
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
Thank you for explaining that to beginners guys.
APIs are definitely key. You don’t have a true platform unless your service can be exposed via APIs.
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?
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
yes, that was a great ending!
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?
good suggestion. i’ll work on a follow up
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.
craigslist is the exception that proves many rules
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.
don’t know what i think but its an issue for sure
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.”
Excellent insight – the API has to be a way for users to augment the already-excellent experience, not a make-up call for mistakes.
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?
it’s not a failed api. it’s just an underused one. and they are putting out a read/write api soon.
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.
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
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.
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.
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).