Centaur Technologies designs for the Industrial IoT. Our sensors typically go inside cargo containers and connect to the cloud wirelessly, often through an API. We aim to go “where no sensor has gone before”, and quite often an API is providing the breadcrumbs for this journey…

Why did we need to develop an API? There is usually a pragmatic aspect to this. An API forces a certain modularity to the design, so that multiple apps may access the same database in an orderly fashion. This becomes important in the context of databases for the IoT where data streams may flow in from numerous Things, while data consumers (human or machine) should be allowed access through some formal authentication mechanism (e.g. we use JWT for now). Moreover, an API provides ideal test fixtures for making the code testable (e.g. we use SuperAgent for that).

But there is often a strategic aspect to an API. It paves the way for onboarding others (especially 3rd party developers) to your service. In an ideal scenario, your customers may use the API to develop their own toolsets and apps over your product (or its underlying database and engines).

But is everyone open to this sort of APIxploitation (to coin a term…)? Not always. Some services will only implement the ‘R’ in CRUD, that is provide read access to the underlying database but not necessarily allow one to add to it in any meaningful way (outside their own UI). That’s not the only bottleneck with APIs; sparse documentation and lack of standardization, especially for the IoT, are some of the typical shortfalls. By the way, we like what iotdb.org is aiming to accomplish by offering some standard semantics in the way IoT APIs could be built one day.

So is the API part of the product? Is it monetizable? Some people go as far as advocating that the API is the product. This is especially true in the case of tiered or freemium services such as Mailchimp and Google Maps, where most commercial usage may originate via the supplied API. Transactional APIs such as PayPal’s or Stripe’s will implement charges per each transaction (digital payments in their case). Affiliate business models such as AdSense and the bulk of the business network comprising today’s travel industry will also rely exclusively on APIs to channel commissions between agents, platforms and providers.

A filling station could advertise an off-peak-hour offer for cheap electricity, by pushing it to autonomous vehicles roaming in its vicinity.

Will these business models pan out well in the IoT? Maybe so. Most IoT products today, especially those in the consumer space, come with an API. Think of a wearable fitness device allowing third parties to develop apps for its users. Access to such an API may typically be free (to promote sales of the appliance) but tiered pay models are also possible – especially when advanced analytics are added to the offering. Regarding IoT infrastructure, platforms and middleware offerings are invariably offered to IoT developers in the form of a tiered API or via a freemium access model.

Interestingly, transactional APIs may also be envisioned especially if Things are to start transacting business with each other. A micro-payments model could be considered where Things may initiate monetary transactions and clear them using some form of blockchain-based currency. Think of your car paying the proximal parking meter using pre-stored Bitcoin.

Finally, affiliate business models should appear at some point. In the context of Smart Cities, one of the ways to enable service aggregation in what is currently a very fragmented ecosystem, could be over the development of API-driven affiliate networks. Municipalities, utility companies, telecom operators and specialized solutions developers could participate in a common marketplace, each one of them enabling partners to offer commercial services over its proprietary database and fleet of Things. In this fashion, a filling station could advertise an off-peak-hour offer for cheap electricity, by pushing it to autonomous vehicles roaming in its vicinity. Anything could flow, as long as the proper plumbing (= API) is in place…

This article originally appeared on the APIlama blog maintained by our good friend @mpetyx. There is also a companion Slideshare presentation.