11 Comments

Summary:

Ebook-lending service Lendle, whose access to the Amazon API was just cut off, has become the latest poster child for a simple maxim: Building your service on top of someone else’s API — no matter how “open” it is — can be a very dangerous road.

Lendle-screenshot3x2

Updated: Lendle, an ebook-sharing service that allows users to find and trade Kindle books, sounds like a great idea — except that it doesn’t work anymore, because Amazon pulled the plug on the site by blocking access to the Amazon API. According to Lendle co-founder Jeff Croft, there was no warning from the online retailer, only a cryptically worded email. So Lendle becomes the latest poster child for a simple maxim: Building your service on top of someone else’s API, no matter how “open” the API is supposed to be, is a very dangerous road.

Update: Lendle has posted an update on its blog to say that it has modified its service as requested by Amazon (removing a feature that allowed Lendle users to synchronize their books with their Kindle account) and API access has been restored. However, the company also said that as a result of the incident it had “come to realize we need to work towards a Lendle product that does not rely on APIs provided by Amazon or any other third party.”

No one knows the downside of this approach better than Bill Gross, the founder of UberMedia, which the veteran Silicon Valley entrepreneur has built into a kind of Twitter client rollup by acquiring services and apps such as UberTwitter and Echofon. Gross originally had a great idea for selling advertising around tweets as well, but then Twitter launched its own identical advertising platform. Earlier this year, after what Twitter said was bad behavior by some of UberMedia’s apps, the social-media platform shut down the company’s access to the Twitter API.

In UberMedia’s case, the company made some changes to its apps, and Twitter turned the API tap back on. It’s not clear whether Lendle will be able to modify the way its service works to make Amazon happy, however. The online retailer hasn’t made any statement about the action it has taken against the ebook-lending service other than to say Lendle doesn’t “serve the principal purpose of driving sales of products and services on the Amazon site.” We’ve emailed Amazon and will update this post if there is any response.

Is Amazon planning its own lending service, or is it simply afraid that more borrowing of books equals less buying? The answers to those questions remain unclear until the company clarifies its reasoning (Lendle says users buy more books after borrowing them).

Twitter used to be the most obvious example of a company that was willing to let developers do pretty much whatever they wanted with the service’s data, and that open approach arguably helped to create much of the network’s value, including popular conventions such as the retweet, the @ mention and so on. But Twitter has been tightening the reins on what it allows for some time now, and its latest pronouncement made it clear certain aspects of its business are simply off-limits for third-party developers.

In some ways, that’s a natural evolution for a company: to be open with its data when it is trying to grow, then to shut down or restrict that as it tries to become a functioning business and make money. Amazon has long since passed that point, of course, and Lendle is only the latest to find out that what it thinks is a good service and what a company like Amazon thinks can be two very different things — and whoever controls the API wins.

Post and thumbnail photos courtesy of Flickr user Will Clayton

  1. The capricious nature of API access is only part of the story. The other part is that you often cannot get rules out of the API owner up front. If Amazon didn’t want people to build something like Lendle, don’t expose the API. If they’re fine with a Lendle-like service but want terms around that (the site needs to drive purchases trackable via an Amazon affiliate code at some level) then say that. But what too many of these companies do is to act open, then shut off API access without clear, transparent reasons. Sure, it’s their right to do whatever they want, but why would anyone ever use an API seriously if they can be killed at anytime for any or no reason?

    Now, a large user might enter into a contract with the API provider, but that presumes 1) that the API provider is set up for that, 2) that they’re willing to do it for smaller companies too and 3) that they don’t bias the contract so that they can still shut you down capriciously.

    Share
    1. That’s a really good point, Rick — a little more transparency from companies about what they want or don’t want done with their API would be helpful. I think in many cases with companies like Twitter in particular, they may not even know what they want until it’s too late.

      Share
      1. I’ll buy that from a new service, but not from Amazon. A few years ago I considered using a bunch of services to enable music lovers to figure out when favorite acts were coming to town… Parse their itunes library XML file, last.fm scrobbles, etc, talk to Upcoming, Eventful, etc, have some way to let them know that an act was about to come to their town, link them to an online ticket agency. Doing it via APIs from those services eliminates a LOT of data collection issues and in past lives I’ve done that kind of thing, so I know how attractive eliminating it can be. Among other issues, though, was the lack of definition around the APIs… I’d have built a service that could be shut off at any point. That wasn’t the sole reason I didn’t move forward, but it was a big issue nonetheless.

        Share
  2. When we were building out our 14 live chat sites eg http://www.LiveF1Chat.com http://www.LiveBaseballChat.com http://www.LiveHockeyChat.com etc etc All of the developers were saying no need to build databases, just use Facebook login to provide access and control.

    Not a chance.

    We allow users to “link” their account to their facebook account (you can post to your facebook wall and your twitter stream from within out apps) but there is no way to use our platform without registering for it first and thats the way its going to have to be – some people see this as a stumbling block, i see it as good business sense.

    Share
  3. I’m just waiting until Amazon cuts off public libraries. I mean really! The though of lending out books for free? Crazy. What kind of business model does THAT have?

    Share
    1. Yes, I thought about that too — I wonder if we would even have libraries now if books had started out digital.

      Share
    2. Most likely, public libraries will purchase the content, and then lend to borrowers through their *own* API.

      Share
  4. Kenneth Cheung Tuesday, March 22, 2011

    Interesting the Barnes and Noble has a “Lendme” function built into their core product for nook books. Even if Amazon feels that this isn’t a “revenue generating” feature, they will be forced to provide this capability by competitors.

    Share
    1. Amazon does have the same useless lending as Nook: not all books, one-time lending, two week max. And the last time a friend tried to lend me a book on Nook? It wanted a credit card number from me: HERS.

      Share
  5. Exactly my point. Use facebook or google or any API for that matter as an added login authentication system but ALWAYS have your own database of users.

    Share
  6. I very much agree with the sentiment of the article. Dealing with these issues has to be part of risk management in any project involving the interaction with other systems via external API’s.

    However – I think the title is a bit misleading. ‘Open API’ – you are talking about PROPRIETARY API’s in this article. Open API’s such as OAuth, OpenID, … are a very different ballgame and in general not controlled by one entity as well as implemented by multiple providers.

    Cheers,
    Leo

    Share

Comments have been disabled for this post