Long Live The Private API

Over at APIevangelist.com, the site's editor Kin Lane has published a blog -- one that I disagree with --- that insults the tech blogosphere in the same breath that it claims there will be no such thing as public vs. private APIs. In that blog, Lane writes:

"the concept of public and private doesn't exist. This is a reality that plays out in conversations between people who don’t fully understand the world of API management—aka the tech blogosphere. If it has an http:// in front of the address, it is a public API—sorry."

ProgrammableWeb does not subscribe to the idea that we should retire the distinction between public vs. private APIs. The nomenclature of "public APIs" vs. "private APIs" are, in fact, a critical part of the conversation that's playing out everywhere in the API economy for two reasons.

First, as "API language" goes, both terms are commonly interpreted by API stakeholders to primarily imply a business decision when engaged in a conversation about API strategy. In other words, when one person says "we'll make that API private and that other one public," everyone in that conversation knows what that person means. When developers hear that an API is private vs. public, they also know what that means. In both groups, there might be some newcomers who don't get it, but it isn't long before they're up to speed. 

Second, but equally important is when businesses and API stakeholders are communicating requirements to API management solution providers. The public vs. private distinction is not only a common language, it will impact solution selection (based on public/private capabilities, cost, buyer comfort level, etc.) as well as implementation specifics.

It's About The Target Developer
Across the API economy, various API stakeholders are charged with aligning their API strategies with their business strategies. Security-wise, those business decisions will often dictate certain technological choices and best practices across the entire IT estate. But picking between public vs. private is primarily not a technological choice. It's a business choice along the lines of Netflix's Daniel Jacobson's often-referenced explanation of LSUDs (Large Sets of Unknown Developers) vs. SSKDs (Small Sets of Known Developers). For example, Amazon's IaaS APIs are broadly available to anyone in the public (aka: LSUD) on a self-serve basis and are, from a business perspective, considered to be public APIs. The term "public" is not used to communicate a technological choice (as in "Let's make it HTTP"), but rather a business decision regarding a target of LSUDs that most closely aligns with Amazon's business strategy and future ambitions.

Although they are based on HTTP (the core protocol of the World Wide Web), and available by way of the Internet, Netflix's and many Walgreen's APIs (eg: the Walgreens Balance Rewards API) are considered to be private in that they are only available to approved partners (aka: SSKDs). They are private programs in the way that some country clubs, though accessible by way of public roads, are private. It's a business model descriptor that is broadly understood by all stakeholders in the country club market in a way that facilitates a common understanding across all sorts of conversations. Extending the country club metaphor a bit further, virtually no one says that a private country club is actually a public country club with stricter security because its entrance is on a public road. To the country club, the word "private" is both a business choice and a designation. To the market, the world "private" as it applies to country clubs communicates "exclusivity."  When, for example, ESPN announced that "we have made the difficult decision to discontinue our public APIs" under the headline "Public API Retirement,"  the entire industry knew what ESPN meant by the word "public."  The same is true for ESPN's elaboration that included the phrase "public API keys" (also equally and widely understood): "Effective today, we will no longer be issuing public API keys."

(Continued on page 2)

Be sure to read the next API Strategy article: LinkedIn to Limit Public Developer Access to its APIs


Comments (7)


Exactly. You have to have private api's based on ROLE for your institution. I interviewed at Target who had api's on separate boxes and I asked 'was this because of traffic?' and they said no they didn't have that much traffic, they just needed to serve it differently for administrators. So I said this was ROLE based then and they didn't understand.

I explained that they were trying to serve the api to users different than to administrators hence the request need to have a ROLE check on it and they came up with a hardware solution rather than a software solution... so each time they need to add a new role, they will have to add a new box which isn't a very efficient solution. They got it at that point as did the manager and saw what I was saying and said they didn't need to add many roles.

I responded by saying, well you didn't think you were going to need to add that administrative role either but there you are. You have to plan for expansion, plan for scalability. Plan for public and private

The request will come down eventually on how to make certain api's private and you will have to come up with a solution for the business and as api's are communication, you SHOULD be able to have some communications be private; not all communications should be public.



Thanks very much Orubel.....  it would be tough to have a productive conversation, especially if you told Target that there's no such thing as a private API and that all their APIs are public? Right?


While I definitely do not agree with Kin's simplistic argument, I only partially agree with your definition as well.

A private API at our company is only for consumption by other company applications, while our Public APIs can only be consumed by registered and approved external entities.

None of our APIs are open to anonymous consumption (LSUD in your definition), though we are investigating stratifying Public into something that mimics your definition with Public Registered and Public Open, but the latter will depend on insuring we can properly manage the consumption and costs.


Hey Madlyb,

Thanks so much for commenting on this piece.  That's an interesting distinction (Public Registered vs. Public Open).  It's true that "Open API" is often used as a means to describe APIs that are open for business to LSUDs and I think "Public Registered" vs. "Public Open" deals with any ambiguity in just "Open API."  Today, "Open API" can also mean that from an intellectual property point of view, the API provider doesn't intended to enforce copyrights or other intellectual property having to do with the API call itself (it may very well have a patent on the business method that's abstracted by the API).  We hear external vs. internal a lot too, with "internal" mapping to your "private API" and "external" referring to your current public APIs. External can of course break down into private or public (private external equating to Public Registered and open public external equating to public open). But those semantics, as important as they are to you so that all of your API stakeholders are speaking a common language are just that, semantics. You have to go with what you're most comfortable with.  The point is that you have a private API, you call it that, and it's a part of your daily API vernacular.


Absolutely agree, Private APIs exist, and will continue to exist.


Good article and some subsequent discussions.

Many of the APIs expose some data behind it. Depending on how sensitive is the data or how much control is needed on the data, the API tends to be referred as Private vs Public. However, most APIs are generally pass through type wherein they are designed with very little access control on them. Every user who is authorized is offered the same type of access to the API something that is not a great design.

At Espresso Logic wherein we help create enterprise class REST APIs to enterprise data, this question comes up all the time. This is why we recommend that APIs should enforce both security/access control and business logic and this should be a required thinking for all API designers.