* How do they handle deprecation?
At some point, they're going to realize that their API design is wrong, could be better, or could take advantage of new patterns, methods, or even customer usage patterns. As a result, they're going to have to restructure and potentially deprecate things. Do they handle it with transparency, honesty or even just make sure your stuff still works?
At Twilio, the 2008 endpoints have been deprecated for 5+ years but still work and - to the best of my knowledge - there's no sunset announced. Yes, all the examples, docs, sdks, etc encourage you to use the new endpoints but the old ones are there. Compare that to Facebook, Google, Twitter, etc which turn on and off APIs and break things with little regard for end users. Which leads to the second question..
* What's their business model?
If they make more money as you use the platform more, that's great! In biz speak, your interests are aligned! They're going to make sure you get started as quickly as possible, minimize downtime, and make sure that your stuff works now and forever. Once again, that's the Twilio model.
If you scale from 1 to 10 to 1M requests/day and they make the same amount of money (or none in many cases), then they're going to be less concerned if you can't make 1, 5, or even 10% of those calls. Even worse, if the API itself is primarily used for market penetration purposes (once again: Twitter), they may treat you as a free R&D group and let you do the exploration and prove the market before they step in.
* Early Twilio employee, current Okta employee, wrote a book on API Design