Some really great points here, so won't rehash those. Some additional things to consider:
- Request size limitations (implicit and explicit, such as only allowing GET and being limited by what can be URL encoded)
- Response size limits, especially for reporting or data retrieval APIs.
- Concurrency limits in addition to rate limiting (e.g. Requests per second limit AND number of queued requests limit)
- SLA have been talked about, but you always need to quadrupole check this and your contract outs based on number of incidents, etc.
- Consider upstream/downstream dependencies, for example Twilio itself is not likely to go down, but one of the regional telcos/carriers/rate centers are. What options do you have then? (Twilio allows SIP trunks from other carriers to be connected for example.)
- Request size limitations (implicit and explicit, such as only allowing GET and being limited by what can be URL encoded)
- Response size limits, especially for reporting or data retrieval APIs.
- Concurrency limits in addition to rate limiting (e.g. Requests per second limit AND number of queued requests limit)
- SLA have been talked about, but you always need to quadrupole check this and your contract outs based on number of incidents, etc.
- Consider upstream/downstream dependencies, for example Twilio itself is not likely to go down, but one of the regional telcos/carriers/rate centers are. What options do you have then? (Twilio allows SIP trunks from other carriers to be connected for example.)