Remember That An Application Is Not Just About Someone Building A Web or Mobile Application With Your API

I encounter regular waves of API providers who are discouraged with the traffic to their API portal as well as the number of developers who are actually building something on top of their API. Many suffer from the hangover of “if you build it they will come” syndrome. Believing that if they just publish their APIs that developers will just show up and build amazing things. While many of us evangelists and advocates have over-promised amazing outcomes when it comes to publishing APIs, many of us in the trenches have long been honest about the hard work it takes to make your APIs something developers will want to use.

Just publishing your APIs to a developer portal is not enough. Having a well designed and documented API is not enough. Making enough noise so that people find your API is a full time job, and ideally it is done by a whole team of people—study how Twilio has done it if you need a working example. Also, you have to regularly re-evaluate what the possibilities are when it comes to building or developing “applications”. This isn’t the API ecosystem of a decade ago where we focused on building just widgets and mobile applications. There are many more ways in which people can put your APIs to work in 2019, and you should be making time to understand what those possibilities are. The chance that some new developer will randomly find your API and build the next killer mobile application is pretty slim, and the real world implementations are probably going be much more mundane and granular.

The important thing to remember about the word “application” is it does not necessary mean a web, mobile, or device application—it can simply mean “applying” your API.  Which in a world of integration platform as a service (iPads), bots, voice, and other use cases, applying your API could mean many different things. Don’t expect that all of your API portal visitors will be developers, and that they will have an application in mind. Most will just be looking for inspiration, kicking the tires, and understand what is possible. Many will just want the value you enable without having to write code or building an application, integrating and working with the services and tools they already are putting to use. Hoping that your API is ubiquitous across the integration pages of other API providers, and across the growing number of iPaaS providers who have emerged across the scene in the last couple of years.

Make sure you are regularly refreshing your view of the API landscape by frequenting the APIs of other providers. Visit their integration pages to see what complimentary APIs they have integrated with. Do you have an integrations page? Go play around with the different iPaaS players on the scene and see what types of integrations they offer, and what types of solutions they offer you to integrate your API. Of course, also make sure you have not just a reference Postman collection describing the entire surface area of your API, also make sure you have introduction, walk-through, and other on-boarding types of Postman collections for your APIs--making sure there is no friction for developers when it comes to learning about your API. The more you invest in reducing friction for your new API consumers, while also baking your API into other existing API platforms, the more your perspective of what exactly what an application is will shift, eventually landing somewhere that is more in sync with the API consumer you desire.