When I first delved into the world of voice mashups eighteen months ago, my then-boss challenged me about business models. At the time, I maintained that mashups, and for me voice mashups, were going to be huge because they were relatively simple to put together and they saved tremendous money for the enterprise. His question was simple; sure it sounded great for the professional services firms, businesses that deployed them and even the tool vendors that supported their efforts… but was there a real play for the people that provided APIs?

The thoughts went like this: if it’s so easy to write a mashup, there’s no reason why the developer couldn’t use a new API for every project. With that sort of churn, and given that providing voice APIs is not that hard, the provider of the API was screwed. For my bosses’ business, he was out of luck. I say not so fast.

There’s more to an API than just functionality – there’s data. If your API provides functionality to a developer, you might also want to think about including data as well. For instance, if you have a click-to-call API, you should also include data based APIs as well. Perhaps the data you provide is simple, such as a history of all the calls made through your system. Maybe the data you provide is clever, like a history of when people answered the click to call, so you can do more intelligent call scheduling. Maybe the data you provide is essential, like recording all the conversations made through your API for governance issues.

In today’s world, it’s increasingly easy to provide the exact same service as your competitor. However, if you have hard to replicate data such as calling records or patterns, it may be impossible for your competitor to replicate that, reducing your churn and making your API sticky.