> The bottom line is that the single most important step in converting developers to permanently use your API in their product is how easy it is for them to get started after they sign up.<p>I take issue with this. If the single most important step to converting developers to /permanently/ using your API isn't something like scalability, security, performance, or functionality, there is something wrong with this world.<p>Just because you get more people to succeed in trying your API at the beginning, if it doesn't work for their use case over the long haul they are just going to leave and do something else: the key word is then "permanently".<p>In comparison, Amazon's APIs are often ludicrously complex. Even if you try to use Amazon's client libraries, they are often ludicrously complex, requiring you to construct object factories to get arguments even for the most common request paths.<p>But, by and large, Amazon's services don't stop working when you get too much data, have well-thought-out authorization mechanisms, have never become randomly slow as lots of users sign up for the service, and are sufficiently flexible to support many different kinds of tasks.<p>The fact that the first time I sat down and used Amazon's APIs it took me a while to get them working (and that some APIs from them I still haven't gotten around to learning all the properties of) is then irrelevant: I could tell they would do what I wanted once I figured it out, and I have never been disappointed.<p>Meanwhile, I've come across tons of random startups, often that have websites that are a "little too Web 2.0" (normally a negative indication for an API provider, btw), whom have APIs (or libraries, or daemons, or services, or programming languages) that are great at first but actually sucked.<p>(I mostly felt the need to make this comment, btw, due to someone else in this thread seemingly arguing against OAuth because, despite being secure, it made the API sufficiently complex that they could no longer use curl with it: that is the opposite method from how you should be choosing an API.)