Numerous Challenges When It Comes To Comparing Even Similar API Plans
06 Mar 2016
I was pushing forward my API plan research this weekend, building on some of the tooling I developed during the last round, and the machine readable API plan format I hammered out late last year to help me define API plans. This time I'm applying it to nine of the SMS API providers I'm currently profiling, trying to get a new view of the plans of SMS APIs like Twilio and Plivo, but also working to continue polishing my 100K view on the SMS API industry.
Documenting The API Plans Of Nine SMS APIs
This last friday I got to work profiling the pricing, plans, rate limits, and access tiers for nine of the leading SMS API providers that I keep an eye on. From their pricing pages I gathered the common metrics, limitations, geographic considerations, pricing, and other element offered by each provider, putting them into separate buckets, standardizing how I record these valuable aspects of each API providers resource. This is a process I'd say 1/3 of the time falls right into place, 1/3 of the time it takes some translation and massaging to make it fit, and the other 1/3 things just don't fit into any common way of thinking.
Identifying The Common Metrics
I found it pretty easy to identify the common metrics applied to SMS APIs, as most everything revolving around the concept of the message and a number. There are nuances to these resources that are being metered, like the separation between SMS and MMS, and a local phone number, toll free phone number, and a short codes, but for now I'm just trying to put pricing into common buckets, by loosely grouping the metrics that are applied via API plans.
List of Pricing Across SMS APIs
Along with identifying the common metrics being applied to SMS APIs, I was able to establish a list of the pricing that is being leveraged across these providers. I have machine readable entries for sending and receiving SMS or MMS, setup and rental fees associated with purchasing numbers, and short codes. I have ways of separating out fixed costs, such as fees, or per unit calls, as well as being able to handle ranges, and different rates and limitation being applied to different packages. It is far from perfect, but I am feeling pretty good about it as v1 of the API plan format.
Linking Plan Metrics To Resources
One big disconnect for me currently is being able to fully understand how metrics, limits, and pricing applies to API consumption, such as a linkage between a specific API plan element, and an individual API endpoint, and method. Another dimension of this is that most API plan elements represent a small portion of all the API endpoints available--meaning you only pay for sending message, procuring a short code number, and not for doing configuration, logging, and other more utility endpoints. I have a way to link each plan element to a specific path or verb, but I won't be implementing until I apply this to more API providers. I am not going to worry about this one right now, as I know it will happen in one of the next sprints for this work.
The Unclear World of Limitations
Another big gray area that I am not sure how I will deal with completely, is the murkiness of how rate limits that are applied. Only in some cases are limits actually broken down in detail, including where the ceilings are. Most of the time, the pricing is used as a governor for rate limits, meaning if you can afford it, there are no limits. For now, I will just state "unclear" if I don't know where the limits are, and most likely just leave as an individual transaction, as opposed to when labeling it as "range", or "unlimited", as I do in other cases. While I think API limits will come into focus as I profile more APIs, I also know this will continue to be a murky area for some providers, either because of a lack of vision when it comes business strategy, or in some cases provides will be trying to obfuscate the limitations so they don't scare consumers off.
More API Plan Profiling Before I Iterate Further
There are many challenges present within as I work to compare these similar API plans, but as a first crack, I'm pretty stoked with what I have been able to accomplish, and make machine readable. In addition to including this data in the API listing for my API plan research, I also broke it out separately into a view that showcases the API plan details across all nine SMS API providers. I find it valuable to look at the plan elements alongside all of the API endpoints, but I also find it extremely valuable to see how the APIs plans size up against each other, without the technical details of the APIs distracting me--I like APIs, more than I like money. :-)
Next. I'm going to move my research into some of the other more mature API stacks like email, compute, storage, and other essential building blocks for websites, mobile, and device based apps. Too establish the draft format for my API plans format, I looked at 60+ diverse APIs, but for this sprint i wanted to target a handful of APIs, present within common business verticals. Before I iterate on the API plan format any further, I want to make sure it works for defining the details of individual API plans, but also does it in a way that makes it easy to compare the plans for similar APIs, in a specific business vertical as well. This SMS research provided me with a first implementation of API plans applied across nine separate, but similar APIs, but it is also available as a machine readable index for the business of these APIs, within the APIs.json files for each API, as well as the APIs.json for the overall SMS API collection.