Skip to content


Subversion checkout URL

You can clone with
Download ZIP
The open API manifesto. Crowdsourced.
Branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


The open API manifesto. To Scale the API economy.


Open APIs, as public web APIs are a wonderful way to share resources over the world wide web. We think that these open APIs can make the revolution the web needs to support the humans-to-humans, humans-to-machines and machines-to-machines communications, in automated, lightweight and efficient interactions. Because of the business behind it, lots of people call “web APIs” open APIs, where they can be open to only one, few, many or all, with restricted to non-restricted usage. These open APIs describe the interface to access to a resource, a data or a service which have often also restricted usage. After the case of Oracle vrsus Google, it seems that even API copyright trolls are pending.

For a better understanding for developers, companies and institutions we decided to work on an ”Open API definition” Lots of people in the industry tried to make it without success in the API space, so we decided to crowdsource it as possible. We’ve made a tour around API experts met in API conferences to build a first draft about it, described hereunder as the definition of open is quite different towards people.

Main principles : We think that these open APIs, to enable a sharing economy on the web need to be :

  • Accessible as easy to discover and to use
  • Public as accessible to everybody
  • Transparent as sharing with the network new resources publicly
  • Neutral as accessible, public and transparent , so non-discriminant, to 3rd-parties usage

The main goal is to find the requirements an open API need to fill in order to be recognized as an open API by the whole industry. The aim of the contribution is to be able to put in the first draft requirements the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document as described in RFC 2119.


New resources to the network

The Open API provides valuable new assets (as resources) to the network to enable the community to build valuable 3rd-parties usages and applications/clients on top of these existing assets.


The Open API has to be visible on the web, accessible as easy to discover, use and implement into 3rd party-apps, with clear specifications, with open source or non copyrighted or non patented clients. Price for accessing the resources can be free or for an affordable fee, or pay-as-you go for its average expected user.


The open API has to follow standards to continue to be consistent with the network and the systems These standards has to be determined by the future of this First draft.

Attribution, re-use and derived works

The provider will authorize any usage of its open API as long as it respects the law and the integrity of the users’ and user’s data privacy. In counterparty, the provider can ask an explicit and visible attribution of the datasource in the 3rd party application.

Neutrality towards people, organizations and usages

The Open API stay open with all potential users regardless of their identity, organization, fields and business sector, as long as the provenance of the data and resource is mentionned explicitely. No Tiering : The Open API has to keep the same policy and pricing for the same level quality of service for every of its users.

ToS and Policy Changes

The open API provider has to have ToS easy to understand. He can change its open API as long as the updated version comply with the open API definition and has to present business and technical changes in a advance with respect of API users. He also have to be transparent about his Business model and the terms in case of acquisition. If an user doesn’t respect your open API engagement by violating your ToS, you engage to explain publicly the reason of the revoking to whom concerned, with notice.


The open API provider has to invest enough human support and technical resources to make its open API reliable to its developers and 3rd party application ecosystem in a way that make things work well for a production usage. If he can’t allocate such resources, he can open source servers to fill this requirement.


The open API provides access to transparent roadmpap, issues, data and resources to enable 3rd parties to act like practionners and build with the providers asset in a deep relationship.

API copyright

API design copyright policy has to be explicitely mentionned and should be into commons.

Something went wrong with that request. Please try again.