The latest development to happen with the cloud is what is called API-first or API-based SaaS companies. What this means in layman’s terms is a service that set up to just connect something with something else using well-documented interfaces. It is hard enough to understand what a cloud-based vendor is selling, but generally there is some physical comparison: a disk drive (Dropbox), an email server (Gmail), a word processor (Office 365) or whatnot. But an API-first vendor is almost like selling a package of air. To give you a better idea, here are some examples of these API-first companies:

• Contentful, which offers an API-based content management system
• Chartmogul, which has an API for web-based charts
• Stripe.com’s Atlas has an API-based Internet payments system
• 18F, a division of the US Government’s General Services Administration, has developed a series of digital services and APIs so that others can access various federally-based data sources
• Tray.io, who is building various connectors to different web services using a drag-and-drop drawing canvas
• Bitwage, which offers banking APIs so companies can pay their employees in Bitcoin. (They have been a “traditional” SaaS vendor, adding this API layer to their existing offerings.)

This last example brings up an important point. The truest API-first companies are those that started out with putting together a great API, without regard for an eventual or legacy product or SaaS offering.

These API-first companies are another degree removed from any physical reality, but it is a cool idea nonetheless. Patricio Robles at the Programmable Web was the first that I found to write about this a few years ago here.  But they have begun to become more common, and add to what you could call meta-API vendors, such as Mashery and Apigee, both of whom offer API management functions and analytics for API-first companies and developers. And there are API marketplaces that have sprung up over the years, including ones from Microsoft Azure, Infochimps and others. These latter places will sell access to particular data feeds that you can incorporate into your own apps.

API-first companies all share several common elements:

• They have no user interface. The idea is for their customers to build their own UI and differentiate based on this value-add.
• You interact with their product or service via something web-based.
• The best API-first companies take the effort to show developers how to become productive within minutes of first use. More on that in a moment.
• Their inherent value is based on their API set. Once you understand this, it is easier to see what they are offering.
• On the other hand, there is less to visually demonstrate about the product, so it can be difficult to explain to potential customers. And the sales cycle is longer, since a company has to convince both the resident nerd and management staff about the worthiness of the product.
• Pricing is typically usage-based, such as the number of requests to their APIs.

Back in the day (say five years ago), when you built some whizzy consumer tech company, you built the whizzy thing first and worried about the APIs later when you had gobs of data that other folks wanted to get access to. Witness Foursquare, which was a darling for a brief moment of time, but now they want to leverage all their data via their API to track commuting routes or popular nightspots or other things in their vast database. But what is happening more and more, as Robles says, is “APIs are designed, implemented and documented before the application that will consume them even exists.”

I first came across one of these with Twilio, which plans to go public this year. That is an incredible statement in and of itself, since imagine explaining what an API-first strategy to your average VC: it could easily be a plot point on “Silicon Valley” (the TV show). Twilio now runs major infrastructure for Coca Cola, Uber and EMC, among others. Their idea is to put an API in front of the switched phone network, so your programs could have access to making calls.

About that part about being productive out of the gate. This is a key aspect of this class of products. As I said, the idea is that you want your APIs to connect something to something else. The more integrations of various services you supply, the easier it will be for developers to build these bridges between their program and an existing SaaS product. This is what Contentful did: they have a variety of integrations with existing content management products, such as WordPress and Joomla, so you can import your existing blog posts and images and make use of them within minutes of signing up for their platform. This means an API-first company has to invest time in a solid knowledge base, lots of programming samples, and installation guides to make sure their potential developer customers can figure out how to use their APIs.

Chartmogul had a post here about how few apps will be built completely from scratch in the future. Companies will be able to launch faster, add new functionality easier, evaluate their costs more predictably, and scale more reliability.

Want to join in? There is now an entire website, naturally, to help you get started. Welcome to this brave new world!