Jul 27, 2011

10M+ API Calls Per Day & More

Are you one of our loyal customers or even just an outside admirer who loves the MailChimp branding and all that cutesy stuff we do? If so, you probably want to quietly click away now because I am not some creative designer or even one of our awesome UI/UX folks. I maintain all aspects of our APIs and have for quite a while. So yeah, those guys don’t like it when I touch things that aren’t code.

3 ½ years ago, right before our v3.0 launch, the powers that be decided they wanted to heavily invest in our API. Sure, we had an API in one form or another prior to that, but it wasn’t versioned or well documented, and did all sorts of other stuff that wasn’t "web scale". At all. That was a time when we were sporting about 40k active customers and looking at a few hundred API users (tops). Before we get into fun things like today’s real numbers, charts, and pretty pictures, let’s take a little stroll through the API’s history from conception….

  • 2007-03-20 – The very first API went out. It let you Subscribe and Unsubscribe folks – that’s it.
  • 2007-11-21 – Someone announced our brand new API (it essentially became v1.0 once versioning was added). That went to 439 possibly interested customers, of which 189 opened it (woot, 45% open rate!)
  • 2008-05-16MailChimp v3 launched. I’d been here about 2 1/2 weeks. And for some reason they let me touch the code. Oh, that’s right, The Chad was the only programmer around. That announcement went to those 40k active customers mentioned
  • 2008-08-10 – We announced v1.1 of the API … to 430 customers who were actually using v1.0 of the API. I’m just going to call that a 98% adoption rate from the initial announcement, ok (puh-lease)? Somewhere in here we also put versioning in place – whew, that was a good idea.
  • 2009-02-24 – We announced v1.2 of the API was coming to 2,160 riveted customers. Yay, growth! Also, this is where I learned what happens when you offer free t-shirts and get another 45% open rate. Whoops.
  • 2009-05-20 – I finally threw in the towel on trying email support and transitioned over to a Google Group. So worth not having to repeat myself! That was necessary because…
  • 2009-05-28 – We announced v1.2 of the API – to 4,362 people (47% open rate)
  • 2009-08-20 – In preparation for our Freemium plan we had built out our infrastructure a ton (seriously, it was completely different), at which point we picked up datacenters.
  • 2009-12-02 – So that Freemium thing really blew up (in a good way). By this point we’d had 19,000 users on the API. Wowzers.
  • … you can also get all of the gory details from the changelog.

Jumping forward to today, just over 188k users have taken our API for a ride. And some people just refuse to upgrade. Here’s a quick look at the numbers across the currently running versions:

  • v1.0 : 102 users
  • v1.1 : 4,156 users
  • v1.2 : 128,121 users
  • v1.3 : 56,413 users

A couple points of note:

  • That’s not double counting someone who has used 2 versions of the API
  • That is an all-time count – people come and go, so don’t expect those numbers below…
  • v1.3 was released 2010-11-15 and picked up 56k users in 8 months, or 7k per month. Woot!

Ok, so those numbers don’t really mean much, so let’s take a look at some ACTUAL growth and usage numbers straight from our API Logs. The graphs below include data from 2010-01-01 through 2011-07-25 – you’ll probably want to zoom in for real detail:

api-calls-per-day-staggered

Here we have calls per day with the version clearly broken out for easy comparison. The light blue line is the aggregate total of calls covering all versions of the API. So in the past year and a half we’ve grown from roughly 1.5 million calls per day to 9.5 million, and we’ve just started peaking over 10 million. Note that these only count real calls that we can pin on a user (as you’ll see in a sec). Here’s another view of that with a stacked area graph (and thus no total) in case that’s your thing:

api-calls-per-day-stacked

No real surprises there based on the total numbers above – v1.2 is by far the most used version,  v1.3 is coming along, v1.1 is dropping off, and v1.0 barely registers (yay!). The first thought upon seeing that is whether or not our new users are starting up on v1.3 like they should or on v1.2. Just to finish this off, here’s a nice little chart showing a simple percentage-based breakdown:

api-calls-by-version

Now the juicy numbers a lot of folks want to see – has usage by users grown? And are they on-boarding with the proper version (ok, maybe only I want to know that)? The same 3 graphs from above, then, are:

api-users-per-version-w-total

So it looks like back at the beginning of 2010 we saw about 3.5k users per day accessing the API. Not too shabby. We can also see very solid user growth with us consistently seeing over 25k users per day these days (hey you guys!). Here’s that same thing stacked:

api-users-by-version-stacked

Oh, that makes me happy – new users definitely seem to be using v1.3 and usage of other versions has either leveled off or is slowly dropping. Good, thanks folks. Finally, here’s the percentage break down of those users across various versions:

api-users-per-version

 

So we can see the per-user percentages by version are skewing farther towards the newer versions of the API than the per-call percentages are. That’s a start, but we’re obviously nowhere close to shutting down anything besides v1.0.

One final note – all of those valleys are the weekends. It could have been normalized, but meh. Obviously we also have a ton of other data in those logs (user agents, which methods are used most, output formats requested, numbers of calls per user, blah blah blah) that we might break out at some point. If you’re nice.

Anywho, so yeah, when Ben (he’s the one who draws monkeys) talks about the API, the Integration Fund and how happy everyone is that that path was chosen, he’s not just blowing smoke.

Speaking of the Integration Fund and our recently launched Connect directory, we’re coming up on 150 listed integrations (ie, ones we know about). Those are generally drop-in-place, you-don’t-have-to-code-anything types of stuff meant for the folks I ran off in the first sentence. That includes everything from little widgets to help folks include signup forms, to freaking full-on integrations with various CMSes and Ecommerce Shops, to various SaaS partners of ours. I have to admit those full integrations really are some of my favorites because:

  1. Those guys know their systems and thus did them right
  2. They rtfm’d and just kind of showed up (actually, all of you who do that are simply my favorites :) )
  3. I didn’t have to learn those systems and code them (poorly, which is how things started)

Ok, so all of that’s cool enough, but lots of folks have a standard API these days, so it’s a little bit less of a big deal (read: it’s expected). And aside from the intent of making it even more friendly via a major new version we have planned (v2) at some point, it’s pretty close to feature-complete when compared to our mainline web app. However, along the way we’ve found people with all sorts of extra needs, so there are several other APIs we’ve released alongside it. Let’s briefly take a looksee at those…

Webhooks

Our Webhook implementation has actually been around for quite a while, but it’s certainly worth mentioning as lots and lots of people have found them to be very helpful. We don’t have firm numbers to share about usage, but it’s sufficient to say that we pretty much can never look at our job queues without seeing them constantly rolling through and out to users’ servers. If you haven’t taken a look at them and you are syncing data back into your platform, they are definitely worth the look. Also, the main API allows configuring them programatically, so we actually have had integrators who will create them on the fly for users, which is just really cool.

Export API

This was released out of necessity. Our main API is fully buffered, so it is, unfortunately, possible to send/request enough data that it blows out the memory on our processes – not cool. The Export API aims to fix that by simply dumping ALL of a particular set of data. Currently there are methods to download your entire list (much like an export inside the web app) and to dump all of the subscriber activity for a campaign. If you’re sitting there with a list of a few hundred or few thousand, that may sound like overkill (and it could be), but we have users who absolutely need to dump lists of 1 million+ or grab all of the stats for a campaign they sent to 500k users+ – makes more sense now, huh? Yeah.

STS API

This is the newest API in the family and was just released in February 2011 when Amazon released their SES API. We had always wanted to offer (and boy did people request) some sort of transactional sending service – but that’s not really what we’re engineered to do. Simply building on top of Amazon and adding some basic tracking stats has turned out to be a big win that didn’t require a ton of effort.

Also, since it’s attached to your account and can therefore use a regular API Key, we’re seeing plugins – especially the full on integrations I just mentioned – start including the functionality to replace core mail delivery systems that things like WordPress, Joomla, Drupal, and Magento use. If you’ve dealt with that stuff, well, sending email directly from your shared VPS somewhere is sketchy at best.

So what’s next?

Glad you asked. About a year ago we tried to launch a Partner API – really the main reason for doing that was a concern that other small business web integrators who run SaaS platforms like we do would run into issues with our IP Connection limits. Turns out, they weren’t hitting those limits (that’s what I get for listening to the marketing department instead of talking to customers, c’est la vie) and what they actually wanted were features that there wasn’t an ice cube’s chance in hell we were opening up to the peanut gallery (that would be you). Those features included things such as checking username availability, creating lists programatically, modifying user plans / account information, increased rate limits, etc. And those things are in the works – but before you even think about asking, know that anyone receiving that access will be thoroughly vetted and have to sign their first born child away (and maybe second), amongst other things. In other words, we’re still deadly serious about the reputation of our platform and not even a super-awesome-big-name partnership that funnels tons of users into us is worth nicking it even one bit. Seriously. Also, if you need it, we’re probably already talking to you or plan on it :)

Really, that API is mostly going to be a re-hash of our standard API with the couple extra methods and some more strict security stuff in place. But that leads me to our final topic …

OAuth2

So, first a short reminder from 4 years ago: it used to be common place to – gasp – ask a user to let you store their username and password for API access (or even just ask for those details once). As time has gone by, everyone has realized that that’s not really a great idea. Problem is, not everyone has the attention of their developers like, say, Twitter does and thus turning off something like our once-suggested login() method for retrieving an API Key can be painful for small users without a dedicated development team. But it must be done.

With everything else going on it’s taken us a little while to get here (admittedly longer than we wanted), but we have an OAuth2 implementation built which should be released soon. If you aren’t particularly familiar with it, OAuth2 provides a secure way to:

  1. Allow your application to redirect a user to our web app so that
  2. The user enters their actual login credentials into our system and our system only
  3. Then we’ll redirect the user back to your app and allow you to retrieve an access token for accessing their account
  4. We then also give the user access in our system to block your application at any time of their choosing

SO much better for everyone. Our main focus for that will be getting the aforementioned SaaS platform integrations and any native mobile apps using OAuth2 to retrieve API Keys for users. Plugins for CMSes, etc. are not going to be good candidates for OAuth2 (if you don’t know why, no biggie), so users will still be able to retrieve API Keys for their account either from their API dashboardOR, better yet (’cause you followed our suggestions, right? Right?) using the handy-dandy API Key Popup we added a while back:

apikey-popup

So, yeah, if you hadn’t realized it, there’s a ton more than "just an API" we’re working on around here. Want to know more? Well, first R.T.F.M. , then you can keep an eye on either @mailchimp_api on Twitter or our API Announcement Google Group.