Methods of Pricing an "API as Product"

Adam DuVander
Nov. 11 2013, 09:00AM EST

Along with the growth of APIs in general has come the emergence of the API as a product. Many times a new startup is entirely an API. When the entire company is an API, you'd better choose the right API business model. When the API is the product, or the whole business, many times this means charging developers to use your API. It turns out, it's not just about how much you charge them, but how. This post will look at the many different ways that API-as-product companies are getting developers to pay for access.

There are three main approaches to how an API might charge: pay as you go, tiered and tiered with a trial.

Pay as You Go

The pay-as-you-go method is likely at the heart of Amazon's success with AWS. Developers pay for what they use. Similarly, the Twilio SMS API has super simple pricing (shown above). In the US, that means one penny per SMS.

Tiered Pricing

If you do even a little business on the Internet, you've likely encountered the tiered pricing of software-as-a-service (SaaS) companies. It's not just for the fast-moving cloud startups, either, as the example above shows. The NASDAQ Data-on-Demand API shows that even established corporations are launching APIs as products.

Freemium Pricing

A popular option amongst SaaS products is to offer a free version. It had been around awhile, but got the name in a 2006 Fred Wilson post. The Full Contact API (shown above) gives developers 250 calls per month for free--when it comes to paying, then it goes tiered.

Mix and Match

As freemium shows, mixing and matching is common amongst API providers to make sure developers at every level get enough usage to see the value. At my employer SendGrid, we actually have all three of the common methods available. Developers can pay as they go, choose a tier or remain free with sending limits.

API business models have matured since the mashup mayhem era that launched ProgrammableWeb. Founder John Musser has a great breakdown of API business models then and now, which also includes the rarely seen unit-based method of charging for an API.

If you're feeling good about pricing an API, now consider that marketing an API as product could be another thing altogether.

Adam DuVander is Developer Communications Director for SendGrid and Contributing Editor of ProgrammableWeb. Previously he edited this site and wrote for Wired. You can follow him on Twitter.

Adam DuVander -- Adam heads developer relations at Orchestrate, a database-as-a-service company. He's spent many years analyzing APIs and developer tools. Previously he worked at SendGrid, edited ProgrammableWeb and wrote for Wired and Webmonkey. Adam is also the author of mapping API cookbook Map Scripting 101.

Comments

Comments(1)

API is old technology, and not very reliable. Modern developers use better languages than API which is obsolete and slow.