In 2011, I started working on building an API program for Eventbrite. We were much much smaller back then and API platforms weren’t the hot topic that they are today.
Eventbrite only had one successful API integration with MailChimp. It was my mandate to drive more developer activity on the API which we assumed would drive business value, but we weren’t sure how we would connect the two. We did what almost everyone else does when they want to accomplish something but don’t directly know how: we launched a series of tests that emulated other successful API programs.
At the time, Twilio led the industry in API adoption– so we started observing their strategies. Twilio’s developer evangelists attended weekend Hackathons and built demos to introduce devs to their API. They also maintained SDKs/libraries for the most popular languages to make implementation a snap. So, of course, we started sponsoring hackathons, building demos, and maintaining SDKs.
In parallel to executing on these initiatives, I put together larger API focused partnerships with top notch products like Automattic / WordPress.com, SurveyMonkey, Salesforce, and plenty of other SaaS platforms.
After 18 months of courting independent developers and larger business development deals, it was clear that only the business development focused channel delivered measurable results.
In hindsight, we can see a clear distinction between Eventbrite’s API and the APIs of businesses like Twilio. I’ve deliberated for years about different ways to distinguish the respective API approaches, but to completely over simplify, it comes down to this: “does the end user have to create an account to leverage API functionality?”
If the answer is “No”, then you’re probably dealing with an API that provides a utility to developers – one that devs can leverage to make their job easier. These can be grouped together as ‘Utility APIs‘.
If the user does have to create an account to leverage the API functionality, then you’re dealing with an ‘Ecosystem API‘, and you have to take a very different approach to building a program and measuring value.
Let’s look at the implications of each approach:
1) Utility APIs: developers might say this app was “Built with Twilio”
Examples: TokBox (video conferencing), Twilio (SMS), Rackspace (hosting), and Parse
When a developer chooses to integrate a utility API, it’s often a commoditized service. Consider Twilio vs its competitors: all services in this space make sure SMS delivers when the client calls the API. This means that these companies have to focus on (1) developer experience (slick documentation, API client libraries, demos), (2) pricing, and (3) being top of mind (attending tons of hackathons).
Growth approaches:
- Hackathons
- Developer evangelists
- Building demos
- Sponsoring events that developers attend
2) Ecosystem APIs: developers say this app was “Built for Eventbrite”
Examples: MailChimp, Eventbrite, Salesforce, Hubspot, Wix.com
For an Ecosystem API, it’s not common for developers to decide to integrate – it’s any businesses looking for opportunities. Large or small, businesses decide to integrate based upon the value that an Ecosystem API provider can provide. We’ve built 130 extensions in Eventbrite Spectrum by proving that we can be a valuable channel of user acquisition for partners. By integrating our API, some partners avoid having to build their own ticketing service so they can stay focused on growing the value of their core business.
Growth approaches:
- Build a strong discovery aspect to get users to adopt partner services (building that incentive)
- Help developers monetize your audience
- Relationship building
These classifications are simplified, and of course there are exceptions to every rule. But as companies build and grow ecosystems around their API, I’d love to start a conversation around different approaches. Let us know what you’ve found and what approach you’re taking.
—–
Special thanks to Brad Geddes, Kyra Ings, and Dylan Serota who read and edited drafts of this post before publishing.