What’s your API’s “Time To 200”?

I would add:

4. A meaningful indication of API stability and planned longevity

5. A viable method to run automatic integration testing during development

I want an honest answer to how often you're expecting to break my integration and cause me extra work, and if you do that, I want to be confident that I've done enough to update my integration so it still works without having to manually retest the entire thing.

Is it really that important that the time to get to 200 should be small? I understand that it may be frustrating to get started, but assuming I am stuck to this API for a long time, I am lot more worried about stability, quality, performance and availability of the system than time to onboard.

A case where it can matter is when there is no clear commitment yet to use that API.

For instance if there is 2 or 3 alternative services, and you want to explore one of them to have a better idea of the trade-offs. Setting up an account and making “real” requests will be your benchmark.

Actually, even for a service with a decent chance to commit to it, there will still be an exploration phase to get an estimate for the implementation cost. Depending on how much the devs struggle to just try the API, the project could get more or less reprioritized for lower hanging fruits.

I spent a good hour just getting the Box cli running yesterday... Which requires a developer account, creating a 'custom app' to facilitate the CLI interactions, going into an obscure admin interface to approve the request to make the custom app, generating a key pair and downloading configurations for the app, downloading npm crud, and sharing data with the service account associated with the custom app, using uids that aren't terribly obvious in the user facing world.

But then it works just fine! :P

While "Time to 200" is an important metric, it's also important to have complete enough documentation for people to effectively use the API. There shouldn't be wholly undocumented corner cases.

For example, I was using the Docker Engine API and I was trying to use the container GET archive call. The documentation says to use a file path, but it doesn't indicate the behavioral difference between using a file path ending in "/" and one ending in "/."

I had to look at the "docker cp" documentation to figure that out.

If your documentation makes it difficult to complete a project because it only covers happy paths or frequent uses, then your users are going to have a rough time.

Both the "Time to 200" and "Time to real project usage" indicate how important usability testing and documentation is.