Editor's Note : I (Mitch) originally wrote this blog post in 2015 when I was a Product Manager at Eventbrite.

Initially, I had to get these thoughts out of my head and written down, so that I could better define the correct strategy for Eventbrite. I needed this internally in order to get buy-in on my strategy from the Exec team at Eventbrite. After it was well received, I realized this perspective could offer way more value if I opened it up to the public. So I initially shared this as a Guest Post on the Catchy blog, where it took off and started some wonderful conversations.

At the time in 2015, just 'having an API' was a very popular feature of many aspiring platforms - but a lot of folks didn't know how to attach the correct Strategy to it. So this post helps define the API landscape and the respective strategies.

Since its original posting in 2015, small edits have been made for formatting and clarity.

-----

Introduction

In 2011, I started working on building an API strategy for Eventbrite. At the time, Eventbrite was much much smaller 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 this 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 the previous 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 users 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.

‍

2 Different Approaches: Utility APIs and Ecosystem APIs

To build your API strategy, it's important to understand the distinction between the two types of APIs and the respective approaches that would work for each type. So, let's dig in to more detail.

Utility APIs

Examples

• TokBox (video conferencing)
• Twilio (SMS)
• SendGrid (Email) 
• Rackspace (hosting)
• Parse (Push Notifications) 
• Stripe (Payments)

When a developer chooses to integrate a utility API, it's often a commoditized service.

Consider 'Twilio' vs it's 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

For me personally, I find that language around a certain topic can be very indicative - when it comes to "Utility APIs" developers might say this app was "Built with Twilio"

Ecosystem APIs

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

Typically, when building into an Ecosystem API, developers say this app was "Built for Eventbrite" (rather the language of "built with", which is typically reserved for Utility APIs. It's funny how sometimes you can intuitively define a concept like this before you're ever able to explicitly write out a complete thought).

Conclusion

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.