Taking A Quick Look At The Leading API Partner Programs03 Apr 2014
I’ve seen a wave of blog posts about additions to the developer and partner programs, of some of the leading APIs in the industry, making me think its time for some more research into the area. Partner programs come in several shapes and sizes, and go by different names, and are something I would like to understand better. I have several Evernote folders full of research on API partner programs, now I just need to polish it and publish it here on the blog, and possibly give it its own research repository on Github.
Many companies consider their API partner programs, a type of partner all by itself. However when I talk about partner or developer programs, it is about establishing multiple tiers of API access, within an API developer ecosystem. When most think of APIs, a vision of an open, public API comes to mind—when in reality, many APIs will have multiple levels of access, with public just being the first rung of the partner ladder.
Some APIs start with signing up to be a partner, and require developers share details of their integration idea, before they can gain access to an API. IBM does this with their Watson platform, requiring developers to share their idea, and wait for approval before they can access resources. I always recommend providing a open access version of API resources, something that is self-service, and can be accessed 24/7 by developers, but this won’t be applicable with all APIs.
To find solid examples of API partner programs, I wanted to start with the API pioneers, as they have been doing this a while, and have a great deal of experience managing very large, mature developer ecosystems.
This early pioneer in the API space crafted their AppExchange Partner Program to have two separate models that developers can take advantage of: ISVforce allowing developers to build, market, and sell apps only to salesforce.com customers at 15% cut, and Force.com Embedded which allows developers to build, market, and sell apps to any customer, with a 25% cut for Saleforce. They know how to do it right, with a dedicated partner community, complete with events and news for software vendors and consultants to tap after joining, then being approved for the Saleforce AppExchange Partner Program.
Amazon Web Services
To meet the demand for quality technical talent, Amazon provides the AWS Certification Program. Amazon provides training and certification of three types of partners: solutions architect, developer and sysops administrator—allowing for an associate, professional and master levels of each certification. Amazon’s focus is on identifying the best quality developer talent to support the demand within its cloud ecosystem, and less about providing access to API resources, which it's business model manages just fine.
After looking at the early API pioneers, the next place to look is amongst the leading social networks, who also have experience in managing very large developer ecosystems, yet establishing their own approaches to successful API partner programs.
First up in the social realm is Facebook with their preferred marking developers (PMD), which allows developers to apply for three types of PMD: Strategic, Facebook Exchange (FBX), and Mobile Measurement. Facebook provides PMD with a badge to demonstrate their certification, and program updates, case studies, white papers and other resource they will need to be successful. Facebook PMDs are showcased in a directory, allowing any business to search and find the resources they need to build apps, tools and features on top of Facebook APIs.
After Facebook, the business social network LinkedIn has invested heavily in their certified developer program (CDP) lately. CDPs are certified by LinkedIn as the best developers available on the LinkedIn platform. As part of the CDP application process, developers have to adhere to the linked in platform policies and guidelines, and await LinkedIn approval that a company meets their approval. CDP is one of 10 separate partner programs that LinkedIn has.
After looking at the early API pioneers, as well as the leading social APIs, and each of their approaches to delivering partner programs, you start seeing the possible motivations behind the leading partner programs—not all partner and developer programs are created equal. While all these API leaders have been working on their own version of their partner programs, one company came along and forever changed how developer programs could work.
To meet the demand for mobile applications, Apple developed their own developer program, allowing developers to select an enrollment type of individual or organization, submit their applications, then purchase and activate their developer accounts—allowing them to develop, test then distribute apps via the App Store. The Apple Developer Program doesn’t just give developers ability to publish in the App Store, then generate revenue for Apple through app purchases, it open up access for developers to be ability to partake in in-app purchases, iAd rich media ads, volume purchases and take advantage of custom B2B app opportunities. Apple's approach gave us all the app marketplace model to apply in our own API ecosystems, and also provides a model for partnership that is less about just developers, apps and API access, and more about distribution to a leading mobile app ecosystem.
This post was triggered after me reading blog posts from Facebook, Twitter and LinkedIn about changes to their partner programs. But after diving into more research, I ended up having a conversation about potential blueprints for API partner programs within our federal government. Unfortunately there are very few models for this new type of API driven partnerships in our federal government, but two existing programs I think come close, are from the USPS and IRS.
As with other API providers, the United States Postal Service (USPS) Web Tools Integrator program is more about identifying quality developer talent, than it is about access to API resources. To be part of the USPS Web Tools Integrator program, developers just need to read the policy guide, agree to all the terms and conditions, register, request to be listed, then await verification and approval by USPS developer program staff. With the USPS example we are getting closer to the precedent I’m looking for, but really falls short in all the characteristics I’m hoping to see in a federal government API partner program.
The only model for API partnerships between the federal government and the private sector is the IRS, Authorized e-File Provider program. The IRS provides developers with planning tools to help them determine their eligibility, the ability to submit an application, which before approval must pass an application suitability check, business background check, as well as individual background checks, which requires being fingerprinted by a trained professional.
Like the USPS example, the IRS partner program still isn't 100% of what I’m looking for, but for now it is the best we have, and is something that really resonates within government circles. My goal in continuing this research is to provide my audience with leading examples of API partner programs from the private sector, but I also am looking to stimulate conversation within the federal government about what API partner programs might look like.
Looking through the approaches by Salesforce, Amazon, eBay, Facebook, Twitter, LinkedIn, and even USPS and the IRS, give me a good idea of the common motivations for deploying a partner program within an API developer ecosystem, as well as some of the building blocks that are necessary to be successful. the partner programs I've reviewed are primarily about identifying the best developers and applications within API ecosystems, that businesses can leverage when integrating with these platforms. Apple and Salesforce brings some interesting audience reach, and distribution opportunities for developers, but the IRS is the only one that comes close to what I’m looking for, in that they use partner program to control who has access to API resources, including the ability to write data to the platform--I think this will be key to other federal government APis.
Overall I think there are things to be learned from all of the APIs listed above. This is why I spend time going through their programs, in hopes of understanding all the best practices available in deploying successful API partner programs. Hopefully you can use my research in your own API partnership efforts, whether your are looking to deploy an API partner program in the public or the private sector.