{"API Management"}

These are the common building blocks I have pullled from my research so far.

Onboarding

Portal

A simple, easily accessible portal for engaging with API consumers has become essential for all API providers. API management providers have emerged to provide portal services targeting API providers, and some companies are also using Github as a focal point for their API management needs.

Getting Started

Developer onboarding is dependent on laying out simple, clear steps for developers on how to register, authenticate, access documentation and code samples, get support and any other details that are essential to API integration.

Self-Service Registration

Providing a self-service registration for a developer portal, allowing developers to signup and get access to an API, 24 hours a day, 7 days a week.

Best Practices

Publishing of a plain english introduction to the best practices around integrating with an API, providing introductory lesson for developers of how to properly integrate with an API, it should not dive into the legaleze and granular detail provided by terms of use.

FAQ

Providing developers a list of the common questions asked of an API platform, with simple answers to each question, allowing them to understand the common problems faced during onboarding.

Service Accord

Service level agreements (SLA) provide a legal framework managing the relationships between API consumers, but service accords provide a plain english explanation of what they expect from a provider, without the legaleze, in a format they can understand in five minutes or less, without calling the lawyers.

Sign Up Email

Providing a simple, informative, personal email immediately upon signup, letting developers know what they need to onboard.

Google Authentication

Allowing developers to create their API account using their Google account, and allowing the to login in the future using their Google oAuth.

Github Authentication

Allowing developers to create their API account using their Github account, and allowing the to login in the future using their Github oAuth.

Facebook Authentication

Allowing developers to create their API account using their Facebook account, and allowing the to login in the future using their Facebook credentials.

Documentation

Documentation

Quality API documentation is the gateway to a successful API. API documentation needs to be complete, yet simple--a very difficult balance to achieve. This balance takes work and will take the work of more than one individual on an API development team to make happen. API documentation can be written by developers of the API, but additional edits should be made by developers who were not responsible for deploying the API. As a developer, it’s easy to overlook parameters and other details that developers have made assumptions about.

List of Endpoints

Before a developer is thrown into the full detail of API documentation, it helps to introduce them to all available API endpoints, getting them acquainted with the resources available. A simple listing of all endpoints provides a quick introduction, that will prime developers for a deeper dive. After reviewing all API endpoints a developer can start to imagine how their application will integrate with an API, further understanding the value the API will bring to their application. Sometimes it's hard to see the 100K view of an API from regular documentation, start with just listing the API endpoints.

Interactive Documentation

There is a new movement in API documentation, one that is moving beyond static, often boring documentation and into a new realm where API documentation is live and interactive. Following in the footsteps of API explorers these new interactive documentation formats like Swagger and Mashery I/O Docs, allow developers to authenticate, navigate endpoints and make requests with live responses returned. In a little over a year, interactive API documentation has gone from a new innovation of a select few APIs, to being a standard offering among many of the leading APIs in the space. There is no better way to get your developers acquainted with an API, than allowing them to interact with your API while reading documentation--turning API documentation into a hands on experience.

API Explorer

API explorers allow users to make calls and explore REST APIs using a web interface. The simplicity of REST has contributed to the extreme growth in the number of Web APIs in the last year, and API explorers are going to fuel this growth. API explorers put the power of Web APIs in the hands of non-developers, allowing journalists, students, politicians, and any tech savvy Internet user to access the data and functionality available via APIs.  

Error Response Codes

Errors are an inevitable part of API integration, and providing not only a robust set of clear and meaningful API error response codes, but a clear listing of these codes for developers to follow and learn from is essential. API errors are directly related to frustration during developer integration, the more friendlier and meaningful they are, the greater the chance a developer will move forward after encountering an error. Put a lot of consideration into your error responses and the documentation that educates developers.

Authentication

oAuth

Providng an oAuth layer to API operations, securing high value APIs, while also opening up a conversation between an API platform, developers, and end-users regarding the access of their content, and valuable data.

Basic Auth

Usage of the basic authentication format that is part of the standard HTTP operations, employing a users username and password as credentials for accessing API resources.

Authentication Overview

Always provide an overview of what type of authentication is provided for an API. Don’t assume developers will know anything about Basic Auth or oAuth. Walk developers through goals behind authentication, with links to tutorials regarding authentication technology. If an API employs oAuth, make sure and take extra special attention to provide clear instructions on how to use, as well as language specific code as part of your API SDKs. After poor API documentation, oAuth integration is the number one stumbling point for API developers.

Key Access

Providing simple tokens, often called API key is a common way to provide access to APIs. Keys are issued uniquely to each developer and even per application. Developers can reissue keys, and manage their access. API providersoften use API keys to track on how developers are using an API through analytics attached to API keys.

Authentication Tester

When possible, provide a testing tool for authentication. From key and Basic Auth to oAuth, allow developers to enter their keys or tokens and validate the credentials they are using, to make sure they are using the proper credentials. A simple tester can provide quick validation that they are doing it right or show them where they are making a mistake, eliminating serious frustration while programming.

Code Management

Github

Using Github for managing of code samples, libraries, SDKs, and other supporting elements of an API platform is essential to operations, while also providing another channel for a platform to engage with its developers.

Application Gallery

Complete, functioning applications built on an API is the end goal of any API owner. Make sure and showcase all applications that are built on an API using an application showcase or directory. App showcases are a great way to showcase not just applications built by the API owner, but also showcase the successful integrations of ecosystem partners and individual developers. Do not hesitate populating an application showcase with your own active or starter kit applications. As with all of the API code, make sure and provide as liberal licensing as possible to ensure developers can be successful with use.

Open Source

An API is inherently an external part of a company. The documention, code samples, SDKs, starter kits, platform development kits and any code related to an API, should be considered external intellectual property and licensed accordingly. Consider open sourcing all of the code associated with an API. Open source will fuel the innovation that is already present in API ecosystems, further reducing the friction experienced by developers in successfully integrating their applications and businesses with an API.

Starter Projects

Many API owners are going beyond just code samples and generic SDKs for their API ecosystems and providing open-source, private label applications built on top of an API that developers can download, modify and deploy. These projects go by many names, but are commonly known as starter kits or projects. Starter kits can act as code samples, and may contain a version of an SDK, but provide a complete application that reflects common integrations with an API. As with samples and SDKs, start kits will speed up integrations, providing developers with the path of least resistance from registration to active API integration.

Community Supported Libraries

In addition to providing your own company developed libraries, showcasing the libraries of trusted developers fro within the API community.

Code Builder

A tool allowing for the generation of client code for various API endpoint.

Code

A page dedicated to providing access to code resources, whether samples, libraries, SDKs, PDKs, or starter projects.

SDKs.io

Making sure your profile on SDKs.io is complete, with up to date SDKs available so users can use in their integration.

Code - Libraries

JavaScript Library

Code libraries in JavaScript for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

PHP Library

Code libraries in PHP for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Python Library

Code libraries in Python for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Ruby Library

Code libraries in Ruby for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Node.js Library

Code libraries in Node.js for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Java Library

Code libraries in Java for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

.NET Library

Code libraries in .NET for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Scala Library

Code libraries in Scala for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Haskell LIbrary

Code libraries in Haskell for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

ColdFusion Library

Code libraries in ColdFusion for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Perl LIbrary

Code libraries in Perl for developers to use in their native language. Libraries are simple libraries meant to introduce developers to any API and are usually not meant for production environments.

Code - Software Development Kits (SDK)

.NET SDK

Software Development Kits (SDK) in .NET (VB or C#) for developers to use when integrating with their applications in the language they are familiar with. SDKs should be expected to be used in production environments.

Python SDK

Software Development Kits (SDK) in Python for developers to use when integrating with their applications in the language they are familiar with. SDKs should be expected to be used in production environments.

Node.js SDK

Software Development Kits (SDK) in Node.js for developers to use when integrating with their applications in the language they are familiar with. SDKs should be expected to be used in production environments.

JavaScript SDK

A client side JavaScript SDK for integrating with one or many APIs.

PHP SDK

Software Development Kits (SDK) in PHP for developers to use when integrating with their applications in the language they are familiar with. SDKs should be expected to be used in production environments.

Ruby SDK

Software Development Kits (SDK) in Ruby for developers to use when integrating with their applications in the language they are familiar with. SDKs should be expected to be used in production environments.

Java SDK

Software Development Kits (SDK) in Java for developers to use when integrating with their applications in the language they are familiar with. SDKs should be expected to be used in production environments.

Mobile Management

Windows Mobile SDK

Providing mobile focused SDKs for developers to build Windows mobile applications.

Mobile Overview

Provide an overview page, dedicated to mobile application development. Page should give equal time to each platform, including iOS, Android, and Windows.

iOS SDK

The trends is clear. Apple is the dominant platform for mobile application development. API owners need to have a clear understanding of what iOS developers are needing for both iPhone and iPad application development. When possible, provide iOS specific code samples, SDKs and other resources iOS developers can employ to make their API integrations successful.

Android SDK

When it comes to mobile development, Google’s Android platform is definitely the number two player in the space, and warrants similar attention as the iOS building block. Consider providing Java code samples and SDKs specifically for the Android mobile platform. Android is picking up momentum in the space and with new devices being released all the time, API owners can’t ignore the platform as a serious contender.

HTML5

While the native app vs. HTML5 app development battle rages on, API owners have to closely pay attention to HTML5 as a viable alternative offering for their API developers, right alongside iOS and Android. For many web developers, HTML5 is a natural transition to mobile development--a factor that may tip the future toward more HTML5 mobile implementations. Big players like Apple, Facebook and Google are investing heavily in the future being HTML5, which sends the signal to API owners, that they should do the same.

Appery.io

A new breed of mobile development platforms are emerging, and the leader of these is a product called Appery.io, from established technology company Exadel. Using Appery.io developers and even non-developers can build cross-platform mobile applications using a GUI building environment. Appery.io provides a suite of API connectors allowing for rapid mobile application development using APIs, with the ability to then deploy as native iOS and Android as well as web mobile applications. API owners should consider working with Exadel to deploy an API connector for their companies API.

Code - Mobile Development Kits (MDK)

Code - Platform Development Kits (PDK)

Wordpress

Providing ready to go WordPres integration, allowing developers, and sometimes even non-developers to immediately put an API to use through their WordPress site(s).

Heroku

Providing ready to go Heroku integration, allowing developers, and sometimes even non-developers to immediately put an API to use through their Heroku platform account.

Drupal

Providing ready to go Drupal integration, allowing developers, and sometimes even non-developers to immediately put an API to use through their Drupal site(s).

SalesForce

Providing ready to go SalesForce integration, allowing developers, and sometimes even non-developers to immediately put an API to use through their SalesForce account.

Joomla

Providing ready to go Joomla integration, allowing developers, and sometimes even non-developers to immediately put an API to use through their Joomla account.

Google App Engine

Providing ready to go Google App Engine integration, allowing developers, and sometimes even non-developers to immediately put an API to use through the Google Cloud platform.

Chrome Extension

Providing ready to go Google Chrome browser integration, allowing developers, and sometimes even non-developers to immediately put an API to use in their browser, with a Google Chrome extension.

Firefox Add-On

Providing ready to go Mozilla Firefox browser integration, allowing developers, and sometimes even non-developers to immediately put an API to use in their browser, with a Mozilla Firefox add-on.

Single Page Applications (SPA)

Angular.js

Providing developers with AngularJS framework integration, allowing them to build single page applications using API resources.

Self-Service Support

Forum

Forums have become an essential building block in API communities for self-service support. A well moderated, active forum can evolve an APIs development area into an actual community. All forum communities will require the API owner to engage developers, keeping conversations active and questions answered, but with the right developers your forum can become self regulating--with opportunities for more senior developers to answer the questions of newer, more junior users, providing potentially free resources for an API owner.

Forum RSS

Going beyond just a forum, and providing an RSS feed for all forum activity. Something I don't see with all API providers, or forum platforms, but is valuable as a signal when I do see one.

Stack Overflow

Developers do not always rely on the forum or support of a single API. They have long established their own communities for support across many public APIs, programming languages and platforms. The leading open forum for this developer activity is Stack Exchange. Stack Exchange provides a community for developers of all types to share knowledge and answer questions encountered during development of any type. API owners need to actively monitor and participate in conversations on Stack Exchange and not expect developers to always engage on their own local API forum. Some API ecosystems like Foursquare and Facebook have even migrated their entire forum to a dedicated Stack Exchange forum, in recognition of the value developers put into the Stack Exchange.

Knowledgebase

Providing a single repository of content, organized by title, and tag, allowing you to search for keywords and phrases, as well as browse for what you need. All knowledge about an API is curated within the knowledgebse, and updated over time.

Direct Support

Paid Support Plans

Going being just direct, or indirect support and providing paid support tiers for developers to use, allowing them to pay by the minute, hour, or project, and get the intimate, direct support they desire.

Email

An email is a pretty easy way to provide support to a developer ecosystem. If users see an email, they will no that they can get the help they will need when integrating an API.

Contact Form

A contact form is a pretty proven way to allow API consumers to submit a comment, message, or request for help. Users are generally used to using a contact form, and will easily identify it as a place they can go for help.

Phone

Much like email, a phone number can be a solid choice for API developer support. Especially if you have a dedicated, partner target audience. Phone can be the instant gratification that developers need when they hit problems, get their questions answered and move forward with their API integration. Not all API providers will have the resources for phone support, but in some circumstances it will do the trick.

Ticket System

Providing developers with a support ticketing tool, using a custom system, or via a popular platform like Zendesk, can be the healthy way to support the needs of an API ecosystem. Not all developers will want to publicly post their problems, and support tickets can be a very organized way to handle the direct support needs of developers, allowing API owners to respond quickly to easy questions, but also allowing them to organize larger scope items into lists that can be used in API product development, providing a direct link between developer support and the API roadmap.

Office Hours

Open office hours is a great way to provide direct support for developers, in a controlled and sustainable format for API owners. Many popular APIs post office hours each week, giving developers an open time they can engage with support representatives via Skype, Google Hangouts or sometimes even in person. Consider the possibility of using API open office hours to support an API community.

Calendar

An active API will have many events that can be shared with its community, ranging from conferences, hackathons and meetups the API provider will be attending, to industry related events that developers can benefit from. A published calendar is a great way to publicize these events, while also showing that the API is actively engaged within the API community and beyond.

Communications

Blog

An active blog can provide a quality SEO presence for an API, attracting developers and businesses to the API. Secondarily a blog can provide essentials communications for the developer community. While researching this white paper and reviewing 6000+ APIs, a blog is the number one way I could tell when an API is dead and nobody is supporting the community. A blog can easily provide the communication to keep an API active and growing, while also be the barometer of whether developers should steer clear of an API.

Blog RSS Feed

Allowing for users to consume a blog in feed readers, and other sites or applications is critical to getting the necessary reach for any API communications. You just can't expect user sto come to your site, visit your blog to keep up to date, and a feed for any blog instantly makes it portable and able to go to where your users are.

Twitter

Twitter as a communication platform, much like a blog is a great way to establish an active presence for an API, providing updates about API endpoints, build relationships with developers and establish partnerships with other API providers. Also in line with a blog, it can be the communication tool that demonstrates your supporting your API, while an out of date Twitter stream can show that nobody is home to support an API--sending the signal developers should steer clear of the platform.

Email

Sometimes your API building blocks are not complex tools or documentation.  They can be as simple as an email address. Of course simply listing an email address as part of your API community is not where it ends. Don't list an email for developers, partners, or support if nobody answers it. Make sure and have a plan for any email addresses you use throughout your API community.  Make them meaningful and route to the right people. Make sure your email accounts are responsive, otherwise people will immediately go to your forums with negative feedback. Consider an email account to provide support for your API community.

LinkedIn

LinkedIn is a powerful business communications platform. While LinkedIn is not the preferred platform of many open API developers, it is the preferred platform of enterprise developers. As an API communications building block, an active presence on LinkedIn is recommended for API owners, it can add a healthy dimension to your communication strategy and reach older, more established developers that may not always be considered when deploying public APIs.

Facebook

Like LinkedIn, Facebook carries a great deal of social weight when it comes to working with developers. Depending on your target developer audience, Facebook may or may not make sense as part of your communication strategy. Facebook is larger than just the individual social network accounts, and a Facebook Page can be a great way for API owners to attract and engage with developers who are building applications. Consider the Facebook effect when assembling API communication building blocks.

Google+

While Google+ is not as popular as Twitter or Facebook, it does have as many active users as LinkedIn these days, and with considerable SEO benefits, it is recommended that you consider Google’s social network as one of the API communication building blocks. Google+ has a tremendous amount of network effects beyond just the social network and Google SEO. Tools like Google Hangouts can be used as part of API open office hours, and events can be used to coordinate API focused gatherings.

Email Newsletter

An email newsletter is a proven communication tool beyond APIs, and while many developers will not be open to receiving regular emails about an API, there are some developers who are still receptive to this format. As an API owner, there is also a positive effect from having to gather thoughts each week for an email newsletter that goes beyond just communicating with the developer community.

Instagram

Using Instagram as a way to communicate with platform users, and let users know there is someone home.

Vimeo

Using Vimeo as a communication channel for educating users about an API platform.

Youtube

Using Youtube as a regular content and communication channel to help users learn about platform operations.

Chat

Providing a live chant mechanism in the developer portal, allowing developers to connect directly with API proviers during regular business hours, or specificly defined office hours.

Updates

Status Dashboard

API owners are asking developers to invest in building applications on their platform. This is asking for a lot of trust, and the best way an API owner can build this trust with its developers is with a transparent roadmap. API roadmaps are usually a simple, bulleted list, derived from the APIs own internal roadmap, showing what the future holds for the platform. Transparency around an APIs roadmap is a tough balance, since you don’t want to give away too much, alerting your competitors, but your developer ecosystem needs to know what’s next. API owners need to find a balance that works for their company, and maintain an active roadmap outlining where the platform is headed.

Roadmap

API owners are asking developers to invest in building applications on their platform. This is asking for a lot of trust, and the best way an API owner can build this trust with its developers is with a transparent roadmap. API roadmaps are usually a simple, bulleted list, derived from the APIs own internal roadmap, showing what the future holds for the platform. Transparency around an APIs roadmap is a tough balance, since you don’t want to give away too much, alerting your competitors, but your developer ecosystem needs to know what’s next. API owners need to find a balance that works for their company, and maintain an active roadmap outlining where the platform is headed.

Change Log

Knowing the past is a big part of understanding where things are in store for the future. A change log should work in sync with the API roadmap building block, but provide much more detailed information about changes that have occurred with an API. Developers will not always pay attention to announced updates, but can use a change log as a guide for deciding what changes they need to make in their applications and how they will use an API. The change log will be another building block to keep developers updated, and reduce overall support resources needed.

Status RSS

Providing an RSS feed for a status dashboard, allowing users to receive updates on any website, and via any RSS client.

Service Levels

Pricing

Pricing doesn’t always apply to APIs. It’s very common to provide API service for free. However, whether or not you charge for an API, you should clarify this for developers. Provide a pricing page, outlining what a developer gets for free and provide clear pricing for any other service levels, so developers will know what to expect as their usage grows. Even if the API is free, API owners should put thought into the future of the platform, set realistic expectations of how the platform will generate revenue to say in operation.

Service Tiers

A well planned API will have multiple service tiers for developers to take advantage of. Before developers begin integrating their applications with an API, they need to have a clear understanding of what services are available to them. Successful API owners need to openly communicate all service tiers available, and provide simple and comprehensive descriptions of each. With no surprises on services available to them, developers can confidently build their applications on top of an API, understanding at which levels they will need to adjust their integration to take advantage of new levels of a platform.

Partner Program

Adding a top level tier to an API program, establishing a transparent partner level for API developers to aspire to. Clearly sharing what it takes to become a partner, what the benefits of partnership are, and potentially list out all existing partners.

Reseller

A formal program for managing resellers of products and services sold via APIs.

Volume Pricing

Providing additional layers of pricing based upon volume purchases, allowing users to better understand their API usage and potentially buy in bulk based upon their past habits.

Certification Program

Allowing developer to get certifified, providing a verified layer of developers that can be used by the platform, and ecosystem partners.

Monetization

Advertising

Advertising is a proven monetization tool when building web or mobile advertising. Many popular APIs are deploying their own advertising platforms or integrating with existing advertising platforms for web or mobile devices. Advertising is not relevant for all APIs, but API owners should consider the opportunities advertising could offer for their API developers. There are many other monetization models being developed by API owners, and goes beyond the scope of this paper. Don’t stop with just affiliate programs and advertising, make sure and look a little deeper.

Affiliate Program

Affiliate programs offer business rewards to affiliates for each visitor or customer brought about by the affiliate's own marketing efforts. Affiliate programs are increasingly being integrated with API developer ecosystems, sharing API revenue with the developers that build applications around the API. Revenue sharing opportunities for developers are a great incentive for them to learn about an API, and build solid applications that consume API services.

Resources

Case Studies

APIs are all about partners and developers building new applications and finding innovative ways to integrate. When anyone builds some notable application on top of an API, develop a case study. Case studies don’t need to be novels, make them short, concise and showcase what a partner or individual developers has done. Case studies will stimulate other developers imaginations, while also showing the API is a viable platform that others are building on top of.

How-to Guides

Many developers can get up and running without any help at all. Other developers need a helping hand, showing them how to use the API and put code samples and SDKs to use. How-to guides can provide the essential resources for developers to get up and going with an API. Start with common integration scenarios and build how-to guides around them, then as new ways of integrations emerge create fresh how-to guides using these new ways of taking advantage of the API.

White Papers

White papers demonstrate domain and industry expertise. APIs are about exposing valuable business resources and assets of a company. Producing white papers can actively demonstrate the expertise a company possess and how the API resources the company offers can solve problems and provide sounds solutions for an industry and business sector. Make white papers a regular part of the API content creation, and when ready, publish to the API area as well as syndicate across the web.

Webinars

Not everyone likes to read how-to guides or case studies. Many developers prefer to have a visual walk through of how to integrate with an API or the case studies of how other developers have built on top of an API. When appropriate, make webinars and videos around your how-to guides and case studies. If video productions of case studies and how-to guides are standard operating procedure, the work can occur while you produce the core paper. Youtube and Slideshare are great platforms for distributing webinars and videos of API resources.

Events

Publish a page with information about any events the an API program will be ateending, or maybe links to video and slide decks from past conferences.

Slideshare

Publish a list of slide decks available on a Slideshare account, providing developers with access to past talks the API program has done.

Codecademy

Creating courses on Codecademy, then publishing them within an API developer area, providing lessons for developers on how an API operates.

Tour

Providing a guided tour of how a platform and API operates, allowing new developers to walk through all aspects of operations in an interactive or video format.

Glossary

A glossary of terms that applies to an industry, platform, and the business or technical aspects of operations, providing API consumers who may not be familiar with sector or platform specific terms, with a dictionary they can use during integration.

Videos

Provides video resources, helping people understand the API platform, how it can be put to use, and any other supporting areas of API operations.

Internationalization

Provide resources that help developers localize, and internationalize their applications to meed the needs of specific global markets.

Service Provider

Mashery

Uses Mashery API service provider for management of the API platform.

3Scale

Uses 3Scale API service infrastructure for management of the API platform.

Apiary

Uses Apiary for their documentation manageent, and the API deisgn lifecycle for the platform.

Research & Development

Labs

A labs environment for an API can be a center of innovation and inspiration for your API ecosystem.  A labs environment ususally showcase experiemental and non-production projects built around your API. Labs can showcase experiemental and research development by your internal development and business staff. Encouraging internal staff members to take time and innovate around your API ccan increase their awareness of real-llife problems faced with integrating with the API.  Showcasing the best of projects by your staff can also boost moral among your staff and introduce a new set of goals to achieve in their job. You may also considering exending Labs to your API development and partner community.  You may need to review submissions and only showcase the best of breed.  A community lab is a great way to encourage outside research & development, and build community within your API ecosystem. The are many incarnations of what an API Labs could be, spend some time and take a look at what a labs at your company may look like.

Ideas

As an API owner you will have ideas flowing from all directions--internally, from partners and submissions from the API community. Establishing a revolving door for ideas is important, if they don’t take hold internally and immediately get used, put them out to the community and showcase them in an idea forum. Encourage developers to submit their own, vote on, and comment or take ownership of ideas. Idea showcases stimulate developers, planting the seeds of innovation every API owner wants to see thrive in their ecosystems.

Opportunities

After you’ve managed developer communities for a while you will find developers are very open to suggestion and pointing them in the right direction. Some API owners are creating sections of their API communities that showcase opportunities for developers to start projects and build applications. A dedicated opportunities page, bundled with an idea showcase and a transparent roadmap will help keep developer activity in line with company goals.

Legal

Terms of Service

Terms of Use provide a legal framework for developers to operate within. They set the stage for the business development relationships that will occur within an API ecosystem. TOS should protect the API owners company, assets and brand, but should also provide assurances for developers who are building businesses on top of an API. Make sure an APIs TOS pass insepection with the lawyers, but also strike a healthy balance within the ecosystem and foster innovation.

Privacy Policy

Privacy policies protect the rights of partners, developers and platform users while also protecting the API owner from damaging activity via the API platform. Like API terms of use, privacy policies need to strike a balance and protect everyone involved, but also allow for innovation and commercial activity.

Branding

Along with the other business assets made available via an API ecosystem, the API owners brand is also being put on the on the line. Branding Guidelines set the tone for how partners and developers can use the resources and assets made available via an API. The branding guidelines will provide a framework for attributing the API owner, how resources can be displayed and provide visual assets to support the company brand. As with terms of use and privacy policies, branding guidelines need protect the API owner but also provide developers with enough freedom to innovate.

Code License

You should make sure al yuor code samples, libraries and SDKs have a default license that helps defines how your code can be used. A license for the cdoe sets the expectations with API consumers regarding how they can use code generated by a cmpany, and also protect API providers and their partners intellectual property. I recommend taking a look at Github's open source licensing page for a nice overview of the options, especially since this is one possible location you will be providing access to your code.

Data License

A data license defines how data resources available via an API can be used. A data license sets the expectations with API consumers regarding how they can use data, and also protects API providers and their partners intellectual property. I recommend taking a look at Open Definition for an assortment of data and content licensing.

Service Level Agreement

A service level agreements (SLA) provides a legal framework for describing what service(s) is being offered by an API provider, with details about level and quality of service, including warranties, disaster recovery, and steps for termination of agreement. SLAs may vary based upon multiple levels of access to API resources, and different API user groups.

Deprecation Policy

An API deprecation policy sets expectations with API consumers about when and how API resources will be deprecated and shut down. These policies help build trust with API consumers, giving them an idea of how much they can depend on an API resource, and what they can expect when it reaches the end of life.

Monetization Guidelines

Providing legal gudelines for how developers can monetize around resources that are available via an API.

Compliance

A page providing compliance related information, covering how a company, platform, and APIs complies with government and industry regulations.

Software License

A licensing applied to the server or other software.

Trademarks

Providing a reference of corporate trademarks that are part of API operations, and developers may have to consider.

Embeddable

Widgets

Widgets are highly functional, API driven JavaScript tools that provide portable applications that can be embedded on any website or application. API widgets provide tools any API user can deploy, and developers can reverse engineer, modify and extend to meet their needs. Widgets really establish an advanced API embeddable strategy and can deliver the value of an API across the Internet.

Badges

Badges are common for displaying content and resources delivered via an API and allow these assets to be embedded on any website or application. API platforms like LinkedIn and Google have successfully employed API driven profile badges allowing any user to take advantage of the power of an API, and grow a healthy API embeddable strategy.

Widget Builder

A widget builder provides a form that API consumers can use to configure a predefined widget that is integrated with an API, allowing them to customize and tailor the widget experience. A widget builder goes well beyond just a single widget, and gives embeddable code more of an application feel.

Buttons

Buttons are shareable snippets of code that often share, syndicate or trigger a variety of events that benefit an API platform. Buttons play an important role in social media and social networks. Consider how Twitter’s share button has made Twitter a global communication platform or how the Digg button transformed social news. Embeddable buttons built on top of an API can significantly extend the reach of API resources.

JavaScript API

A complete JavaScript API that developers can use to build and manage their own JavaScript integrations with an APIs resources.

Environment

Sandbox

With the sensitive information available via many APIs, providing developers a sandbox environment to develop and test their code might be wise idea. Sandboxes environments will increase the overall cost of an API deployment, but can reduce headaches for developers and can significantly reduce support overhead. Consider the value of a sandbox when planning an API.

Production

When planning an API, consider if all deployments need to have access to live data in real-time or there is the need to require developers to request for separate production access for their API applications. In line with the sandbox building block, a separate API production environment can make for a much healthier API ecosystem.

Simulator

Providing an environment where developers can find existing profiles, templates or other collections of data, as well as sequence for simulating a particular experience via an API platform. While this is emerging as critical building block for Internet of Thing APIs, it is something other API providers have been doing to help onboard new users.

Templates

Predefined templates of operation, when a new environment is setup, either sandbox, production, or simulator, it can be pre-populated with data, and other configuration, making it more useful to developers. These templates can be used throughout the API lifecycle from development, QA, all the way to simulation.

Developer Account

Developer Dashboard

Much like the landing page for the entire API platform, developers should have a single dashboard for getting at all their tools, metrics and information they need to successfully manage their usage. Developers should not have to ask, or look around for their account and access information--they should have a single place to obtain what they need.

Account Settings

Along with password reset, access to their basic account detail and settings is standard operating procedure for any platform. Don’t make developers look for their settings, give quick access to settings and allow for easy updates.  If developers do not have access to change their settings themselves, they will be asking you for assistance requiring additional resources.

Reset Password

The need to reset an account password access is pretty standard operations for any online platform. Provide the necessary tools for developers to gain access to their account if they lose their password.

Application Manager

Many popular APIs are becoming application centric and provide developers with tools for managing multiple applications or development projects. API owners should consider how developers will be building applications on top of an API and consider that many will need multiple access keys for their separate applications or user groups.

Usage Logs & Analytics

Rate limiting will be part of any API platform, without some sort of usage log and analytics showing developers where they stand, the rate limits will cause nothing but frustration. Clearly show developers where they are at with daily, weekly or monthly API usage and provide proper relief valves allowing them to scale their usage properly.

Billing History

Obviously if an API is entirely free, billing history is not necessary, but if any tier of API requires paid access, provide clear and easy access to what a developer has been billed, allowing them to access and download their billing history. Provide tools for developers to update their billing and account information easily, as well as support for their billing questions.

Message Center

Providing developers with a messaging system within their developer accounts, and communicate with API providders, and receive system updates.

Github Authentication

Allow developers to create and login to their API developer account using their own Github account. It is easy to allow Github oAuth to be used, in place of making developers create yet another account.

Delete Account

Developers have the ability to delete their account from within their account portal.

Service Tier Management

The ability to manage your account service tier within a password protected portal, giving developers the ability to change their pricing, and service tier. 

Reciprocity

Terms of Service

The Terms of Service (TOS) is the central hub which makes the API economy work (or not work). TOS is where the protections for platform owners, developers and end-users exists. Restrictive TOS can suffocate the reciprocity of platform, while more sensible ones allow for the movement, and collaboration around resources that will make a platform thrive. 

Data Portability

Providing users with the ability to get data out of a system through a bulk download and via an API is essential to reciprocity existing. Along with other basic web literacy skills that every user should possess, every person should demand that any services they sign up for, should allow for data portability of all their resources. 

Automation

Providers like Zapier and IFTT are delivering API automation services for hundreds of popular APIs, allowing developers and end-users to further automate their operations across multiple platforms, allowing anyone to better manage their resources using very simple API driven workflows. 

oAuth

While not a perfect standard, oAuth is the best we have when it comes to providing an identify and access layer for API driven resource, one that allows for reciprocity to occur within a single API ecosystem, and between multiple ecosystems. oAuth gives the platform, developer and end-users a (potentially) equal role in who has access to API driven resources, governing how reciprocity is realized. 

Integrations

Integrations showcase other 3rd party platforms that an API provider is already connected to, providing ready to go platform integration solutions that any developer can take advantage of. This is right between reciprocity tools like Zapier, and not quite platform development kits (PDK).

Zapier

Provides default Zapier integration, and usually is showcasing it within an API or developer area.

Security

Security Overview

An overview page outlining the security practices, and technology for a platform. Being upfront with developers about security practices of the platform, and what is expected of developers, leads to healthier, and stable platform operations.

SSL

Providing SSL for API endpoints, and developer account, ensuring that end to end encryption is available for all aspects of API integration.

oAuth

Using oAuth to secure an API, providing identity and access management for not just platform developers, but also allowing users to have some control over their own content and data that is accessed via an API.

Rate Limits

Rate Limits Page

Developers need to understand what the limitations of API usage are upfront. Rate limiting an throttling of API access has become commonplace to manage security, and resource load. This building block is about providing a single page explaining how this process works, setting expectations with API consumers.

Rate Limit Information Inline In Docs

In addition to a rate limits page, explaining information about limitations on API usage, some API providers like Twitter are including rate limits within API documentation. With this approach, each API endpoint has its related rate limits published alongside other details.

Account Rate Limit API

As API usage grows the need to be able to programmaticaly manage your account is increasing. Some API platforms also provide APIs for the management of platform operations. It makes sense that API providers should also offer an API for getting rate limit details for their account.

Corporate

Team Showcase

Provide a simple team page, showcasing the team behind the API. Include photos, personal stories or bios, and any relevant social media accounts like Twitter and Github. Showcasing the team behind an APIs, gives the API personality, and helps build trust with consumers.

Management API

User Management

Allow API API consumers to manage their own accounts via an API management API, enabling users to create, read, update, and delete information associated with their account--fields may vary, depending on what information each API requires for user accounts. 1) User Create 2) User Read 3) User Update 4) User Delete

Account Management

Allow API API consumers to manage their own accounts via an API management API, enabling users to create, read, update, and delete information associated with their account--fields may vary, depending on what information each API requires for user accounts. 1) User Create 2) User Read 3) User Update 4) User Delete

Application Management

Ideally each user can have multiple applications, consuming API resources at various rates. This allows for the most flexibility in API consumption, but may vary depending on what API management infrastructure employed. This API should allow for management of all applications, with secure control over application keys. Additionally, there should be analytics available, with a short, simple, but robust list of metrics. 1)Application Plan List (per isolated service) 2)Application List 3)Application Create 4)Application Read 5)Application Update 6)Application Change Plan 7)Application Key List 8)Application Key Create 9)Application Key Delete 10)Application Usage by Metric

Service Management

Enable API consumers to retrieve information about plans available for a specific API, or stack of APIs. Allow for listing of plans, and the features available for each plan. Also recommend considering the ability to set default plan for an account, enabling smooth application management. 1) Service Plan List 2) Service Plan Feature List 3) Service Plan Set To Default