This ProgrammableWeb series on getting the most ROI out of your API tracks all of the major decisions that you make as you build an effective and successful API Strategy.
Our journey started by merging business and technical aspects, before then focusing on some of the business decisions like alignment with overall business strategy, building internal support, and identifying a viable business model for your API. Once these sorts of decisions have been made, the API becomes more of a technical concern with architecture style, specifications, tooling, and security dominating the decision tree. Now that the API is published and external developers are beginning to consume it, our focus shifts again towards a balance between business and technical issues. How does a business leverage the technical API to grow a developer community?
A business often introduces an API strategy when it's looking to move from a product focus to a platform play. When a company looks at leveraging a platform business model it's evaluating using a microservices or modular type of IT business architecture to open up assets (whether digital or real) to partners, suppliers, third parties, and customers who can then create their own value chains. This approach reduces the costs associated with building and distributing finished products that customers must use as intended. By providing more modular assets, the costs of developing full products is lowered, because customers can use only the components they want. Costs of integrating those assets for a customer's end use are also moved on to the customer.
Let's look at two examples, one digital and one with a real-world asset.
U.S. bank Capital One recently opened up some of its capabilities via API. One API it's now offering is a Credit Offers API. This API allows the bank to pre-qualify potential customers for one of their credit card products. Before their API, Capital One would have needed a process for individual customers to come into the bank or visit its website and enter personal information. Then based on this information, the bank would assess (perhaps programmatically) which credit cards and for what amount these could be approved. It could then proceed to providing that potential customer with credit card application details. In some cases, it might have been working with external partners who wanted to offer their pre-qualified credit cards to the Capital One customer base. In this case, the bank would have needed an account manager to work with that external partner and to arrange a process whereby the bank could vet all of its partner's customers as they need credit approvals.
By providing the Credit Offers API, many of these administrative and account management costs are reduced or removed. The API means that all potential customers applying for pre-qualified credit can do so directly, even if they're doing so through Capital One's website or through one of the bank's external partners. The external partner pays for the costs of integrating the API, rather than the bank allocating an account manager resource, so costs to promote pre-qualified credit to customers is both reduced and more targeted. Capital One can now open up entirely new target market funnels by working with partners who can provide credit card services to a wider range of customer segments than the bank could if it were promoting them themselves in traditional ways.
In this case, a digital asset (the credit card approval workflow process) is opened up as a new capability via API and provided to third parties who then integrate it themselves into their products and services. The bank pays the costs of creating and maintaining the API, while the integration costs with a wide range of potential external partners is borne by the partner themselves. The bank can then create a new revenue-sharing model in place (as is the case with Capital One's Credit Offers API), whereby partners who bring in new credit customers receive a referral commission.
Businesses can open up real-world, physical assets via API, which creates cost savings and generates new income streams. Parking garages are an emerging capital infrastructure area that is keen to use APIs to increase revenue and reduce costs. By implementing individual sensors for each parking bay, parking garages gain a detailed, real-time knowledge of the parking spaces available for their customers. They can provide an API so that other services, such as GPS navigators, can integrate that data into their maps. By providing this data as an API, parking garages avoid having to create a bespoke integration solution with every GPS map supplier. This reduces costs, and pushes those costs onto GPS providers who would spend their own developer time and resources to integrate a parking garage's API. Providing this capability also generates new revenue for parking garages as they get to optimize their availability. Vacant parking spaces are promoted to a customer audience who's actively looking for parking locations (by GPS), thus improving the revenue generation of the parking bay. It also reduces more broadcast promotional methods (like street signage) that many potential parking bay customers may overlook. Services like VIMOC Technologies are working with Redwood City in California, for example, to provide this sort of parking bay optimization. It's based on similar systems like HotelTonight, which uses APIs to allow hotels to offer last minute deals on their unbooked hotel rooms.
By moving to a platform model, businesses can make more of their data, assets, and services available in modular form, reducing the costs of creating finished products and instead pushing some of the integration costs onto the platform consumers. Both the business API providers (when consuming internally) and external parties can develop new products more quickly by using or reusing the APIs.
Moving to a platform approach creates multiple effects. One of the biggest goals achieved by moving to a platform model is to create an ecosystem around your core business. Developers create more products and services based on your company's core offerings. These new products introduce your business to new markets or to customer segments that were previously uninterested in your business offerings. Often apps and integrations built with your APIs add new functionality to your core products, which strengthens the value of your products to current customers. External parties building on your APIs become your business champions and advocates as they encourage others to use products and services that make use of your APIs.
One of the better examples of a company that built an ecosystem around its platform in a way that third-party developers became an entirely new channel of business is Salesforce.com with its AppExchange program. Today, Salesforce claims that well north of 50 percent of its revenue is driven by the consumption of its APIs. That same percentage is now over 90 percent for Expedia and its APIs.
Leveraging an API strategy to move towards a platform approach may have been one of the decisions you made when first exploring the business model behind your API strategy. To be successful at creating an ecosystem around your API, you must be committed to building an engaged developer community.
As part of building an API team, you may have already allocated a role that will be responsible for building a developer community. Sometimes, this role is within the product manager's job description. Where the API strategy is sufficiently large enough, or when high growth from the API is expected, a developer evangelist or developer advocate role is created. This increasingly important role is responsible for mapping a strategy for increasing adoption of the API amongst a developer community. Developers are very specific business customers with their own motivations, pain points, and perspectives. In general, developers are more cynical about traditional marketing and are looking for quick solutions that they can implement with the minimum of fuss. But beyond generalizations, many types of developer audience segments might want to use your API. A Developer Advocate/Evangelist can define each developer persona, the most prominent use cases for your APIs, and map developer resource content creation and strategies — from online tutorials to hosting meetups to attending tech conferences — that best match your identified developer audiences' engagement preferences.
In 2015, I conducted an extensive research project for ProgrammableWeb that looked at the tactics that some of the fastest growing API developer communities used to grow their developer base and keep them engaged.
We reviewed eight API examples that had all seen rapid growth. Using social media counts, GitHub usage statistics, SimilarWeb.com developer portal visitor statistics, and other open data sources, we identified what were the key growth multiplier tactics used by these businesses to maintain their developer community and to continue growing new developers.
At the core of any developer community are a number of assets that must be in place:
- Clear terms of service for the API
- Engaging documentation
- Code snippets and code for a sample application
- A self-serve API registration
- Responsive error messages
- An API specification format or other metadata
- Sandbox environments
- An API uptime status page
Once these tools are in place (Box 1 in the following diagram), you as an API provider can continue growing your community by consistently adding new developer community features.
The subsequent boxes refer to each stage of continuing to grow your developer community:
Box 2. A clear service level agreement and pricing plan that documents the API business model and offers a generous freemium or trial usage tier as a minimum sends credibility and trust signals to developers. Another option connected with this sort of offering is the ability for developers to experiment with an API console or play in an API sandbox without having to obtain their own dedicated credentials. Some API providers, for example, support this type of activity through a publicly available API key. This console or sandbox should resonate and reinforce the business model definition, developer personas, and API consumption use cases that the API provider has identified.
Box 3. A steady stream of new developers need to discover your API by finding it listed on one of the major API portals. This includes independent catalogs like ProgrammableWeb and Apis.io, as well as platform-based marketplaces like Microsoft Azure, IBM Bluemix, Blockspring, and the GitHub integrations directory. Some catalogs like Hitch and SDKs.io will automatically list an API from an API specification that is added to GitHub. When thinking about where to list your APIs and which marketplaces to participate in, you should weigh the overhead that goes along with maintaining those listings. Is there a cost involved? Can you contact a human for support? If a marketplace is involved, does it require you to build and maintain some form of marketplace-specific integration? For example, with an eye towards maximizing discovery, Intellexer runs two version of its APIs; an unvarnished one that that's listed on ProgrammableWeb and a carbon copy built to participate in the RapidAPI.com marketplace. However, running two separate endpoints also requires more resources.
Box 4. To further reinforce this discoverability mechanism, make use of commonly known search engine optimization techniques as well as search engine marketing (budget permitting) in your developer portal text and API documentation web pages. The majority of developers still find out about APIs by doing an online search. Posting your tutorials and links to sample code on other sites (like ProgrammableWeb, for example) and engaging in community discussions around a broader industry domain on StackOverflow and other developer sites are also good ways to increase visibility on search engines, stake your market position, and demonstrate that you prioritize community engagement.
Box 5. Best practice API providers each had growth spurts in their developer community when they released SDKs for their APIs and made them available on key platforms like GitHub, Ruby Gems, npmjs.org, and other language-specific distribution channels. For example, after two growth spurts from moving to General Availability and from creating a presence on GitHub, API-first CMS Contentful saw a jump in developer adoption following the release of its iOS SDK. In the best examples, API providers leveraged platform effects by encouraging the developer community to create their own wrappers and tooling to use with their APIs and promoted community members who provided open source projects based on their APIs.
Box 6. Once a developer community starts to build, API providers need to take ownership of their platforms and their ecosystems by creating a marketplace or showcase that lets third-party providers share the apps, services, and expertise they've built around an API. For example, vehicle sales site Edmunds introduced a marketplace where developers accredited as proficient with its API could market their integration services to businesses that wanted to use Edmunds' APIs. Developer tools provider Atlassian created a marketplace where app providers who've integrated with Atlassian APIs can sell their apps. Over the past five years, Atlassian facilitated $250 million in sales through this apps marketplace, keeping 25 percent revenue share for sales generated in the marketplace. Forward-thinking API providers know that developer-consumers of their API are businesses themselves, and they understand they're invested in helping their API consumers succeed and grow. After all, these developer-consumers are using an API provider's technology as a raw good in their product chain.
Box 7. Now that the developer community is flourishing, an API provider can add new customer segments to its business model, for example, by creating support for non-technical users of its API. These may be in the form of IFTTT and Zapier integrations, Blockspring functions, Google Sheets add-ons, widgets, or visualizations.
Box 8. Finally, API providers should create tutorials and content that speaks to the wider industry vertical in which their APIs are operating. Instead of creating documentation material just for using their APIs, API providers should encourage use cases by creating materials for products and business approaches in the wider vertical and then showing how their APIs are leveraged in that market. For example, in our study, we saw how WePay created tutorials to help startups create marketplace platforms. As developers build these marketplaces, WePay showed how its payments API could drive the functionality of that marketplace.
In our next chapter, we look at decisions around building the developer community entry point: How Do I Create a Developer Portal?