This is a question I get a lot:
Why doesn’t Trade Me have an API?
It’s actually a slightly frustrating question for me to answer.
Internally I’m usually the one asking this question. Externally, at places where technical people gather, I’m the one defending the fact that we don’t have an API and, what’s more, have no immediate plans to build one.
Nat Torkington’s recent post has some of the answers.
It’s not that we haven’t thought about it. There are some legitimate reasons why we’ve chosen to not build an API to date. I thought it would be interesting to talk about some of these and get your thoughts.
Some questions to think about
Would we need to communicate all changes in advance to third party developers? If so, how much in advance? We’re constantly making small changes to the site. We generally deploy site changes twice per day. The cycles can be very short. We sometimes deploy something in the morning and then tweak it later that afternoon. Anything which threatens to slow us down is quite correctly frowned upon.
What happens when we need to make breaking changes to the API? Do we version the API and continue to support older versions? If so, how long do we leave this support in place? If not, what liability do we have if we break a third-party application?
How do we deal with authentication? We put a big effort into keeping Trade Me safe for buyers and sellers. We have a full-time team working on this. One of the problems this team deals with is phishing of members login details. We have a simple and consistent message for members: don’t enter your Trade Me email address and password anywhere other than on the Trade Me site. So, obviously allowing third-party developers to build tools which require our users to enter their login details is inconsistent with this. To solve this we’d need to build an alternative authentication process – e.g. the token based approach used by upcoming.org.
Are we prepared to invest in creating an eco-system where third-party developers can profit? As Nat pointed out to me when I discussed this with him, one of the reasons that Amazon have been so successful with their new web services is that they are creating more value then they are capturing. In other words, they are leaving some money on the table for the people using their API.
Are we prepared to allow our customers to become dependant on a third-party tool? If somebody created a really wicked tool using the API, and lots of our users started to use it, would that limit our ability to innovate that the same area? This is a dilemma that eBay have started to encounter with their API, where they have created listing tools which compete directly with third-party tools built on top of their API. At the moment I’m not sure we’re prepared to let others build something we then wish we had built. Is that bad?
How do we protect the user experience? How do we protect our brand? We’re currently very protective of both of these things, for very good reasons.
How do we protect our infrastructure? In the past we’ve had to ask people to discontinue or specifically block access to automated external tools which were causing us pain. To an infrastructure guy there is a fine line between a well-meaning but poorly implemented external tool and a Denial of Service attack. In fact, we currently prohibit the use of any “robot, spider, scraper or other automated means to access the Website or information featured on it for any purpose” in our Terms & Conditions (see 4.1 c).
If we build it will they come? Are there enough developers in New Zealand to justify our effort in creating an API? How many people will actually use it? How many people will use the applications they build on top of it?
Do we have bigger fish to fry? Keep in mind that any development work required at our end would be at the expense of something else. Is an API just too much work for us for too little reward? Any argument in favour of an API need to be more compelling than: all the cool kids have one. :-)
What would you do if you were in our position?