In addition to what has been mentioned already (esp. backwards-compatibility): * Ability to customize / extend I'm assuming your API is targeted at a business

In addition to what has been mentioned already (esp. backwards-compatibility): * Ability to customize / extend I'm assuming your API is targeted at a business domain (vs. an infrastructure API like an email API). The API vendor will do his best to cover all major use cases within that business domain. But expect that your project has a minor use case, or is the first project to ever need feature X. The vendor most likely won't want to implement this feature. (This isn't necessarily bad - in fact it is good, if the vendor would add any random feature to his API, it would evolve into a frankenstein that is a nightmare to work with) However, the vendor should have features and patterns/best-practices on how to solve those cases. E.g. in addition to the API vendors data model, you should be able to add your own data (like https://stripe.com/docs/api#metadata https://stripe.com/docs/api#metadata) and you should be able to react to events to add custom behaviour (e.g. https://stripe.com/docs/webhooks https://stripe.com/docs/webhooks). * Quality of documentation and support A lacking documentation, especially in combination with bad support, can slow down development significantly. Some APIs also have a good community outside of the vendor (e.g. it's active on Stackoverflow), take that into consideration as well. Also, are the POs and Devs active in support? If yes, this is a good sign IMO, because they're trying to stay in touch with their customers. And it'll also raise the quality level of the support, because - if you run into trouble - you can escalate to someone who really knows what is going on. * Good SDKs in your language Some API vendors offer great SDKs. They can be a huge timesaver, e.g. if they provide models for all their endpoints, they provide additional helper methods ontop of the API, and they convert data-types into language-native objects (e.g. Money isn't a native data-type of JSON, but of most languages). It is also valuable if the SDKs (and docs) come with lots examples in your language. Some SDKs are okay-ish, especially if generated from Swagger/Raml. Some generated ones are a bit strange and it may be better to work directly with the API if it let's you craft your models in the way you need them to. Some SDKs are a nightmare. We had one that leaked threads and killed our servers after a couple hours... not fun! * Development workflow As a dev, how can you use the API for testing? On staging? Does this incur additional costs? You may need to reproduce a bug from your production API. It's helpful if you can copy the production data into your dev project easily. (I'm an API dev @ commercetools)