An overview of the email API
With apologies to all who appreciate the particular genius of the 1967 film The Graduate, “I want to say one word to you. Just one word. Are you listening? APIs.”
These days, if you belly up to any bar (or spirits-free meet-up, if you’re so inclined) frequented by tech industry types, chances are you’re going to hear certain buzzwords. I can almost guarantee that “the cloud” and “API” are going to be among them. Sure, roll your eyes. I’ve been there, and I’ve been among those that smiled at a recent Internet meme that declared, “There is no cloud; it’s just someone else’s computer.”
But, when I really think about how tech and its use in the real world has evolved over the past decade, I stop dismissing those words as mere jargon. After all, almost every digital service I use today actually lives “in the cloud.” The bits that make up this blog actually live in the cloud, not a specific server my team maintains. So do the emails I get from readers and the music I listen to while writing. So do most of the web sites I visit and do business with. Unlike the early days of the Internet, when I first began working in this industry, server outages are all but a memory. In fact, the notion of a discrete “server” has all but been eliminated for most applications.
How did this happen? A lot of things made it possible, but the evolution of APIs are key. APIs (“application programming interfaces”) are the fundamental method by which all the virtual infrastructure embodied by the cloud is interconnected. The cloud could not exist without them. Even among business users, “API” has become a ubiquitous part of today’s technology vernacular. But, how APIs actually work, and their key role in the cloud revolution sometimes is taken for granted. We assume they just work.
A simple analogy is with the power outlets in the wall of your office or home. These receptacles provide a standardized interface to connect an appliance to the power network. Simple, right? Yes, it is. But look a little more closely, and that standard gets a little more complicated. If you have an older house, some of your outlets might not support the grounding function of three-pronged plugs or the modern, polarized version of two-prong plugs. Moreover, your electric clothes drier may require a special, oversized plug that connects to circuits that pull more power. Of course, if you’re traveling to the UK, you’ll need a special adapter to plug in your laptop, because it’s a different standard over there. Oh, heck, might as well bring the whole adapter kit with seven types of plugs to accommodate the other countries you’ll be visiting, too. And there are all kinds of extra connection standards for industrial applications that go well beyond what you or I encounter in our everyday experience.
APIs have a similar quality. They are the standard way for one piece of software to plug into—to invoke the functionality of—another piece of software. APIs connect disparate systems, services, and technologies. They are, in short, what makes the virtual infrastructure of the cloud possible. And email APIs are how any app or service can add email without reinventing the wheel.
However, APIs historically were highly idiosyncratic, with very little standardization among platforms. They were clumsy to code, difficult to invoke, and often poorly performing with limited scalability. It’s not a surprise, then that programmers and IT decision-makers alike often treated them as an afterthought to their overall technology implementation and were loathe to rely upon them in mission-critical contexts. In light of the constraints of both hardware resources and API performance, most developers chose to keep everything under one roof in a monolithic codebase optimized for a specific hardware environment.
So what changed that moved APIs from little-loved feature of monolithic applications to the all-but-invisible linchpin of the modern cloud? Three major developments are responsible for the upending of this dynamic and making today’s architecture possible:
- The rise of the Internet as a ubiquitous web that connects nearly every computer (or other electronic devices, whether televisions, phones, refrigerators, and thermostats, inventory control systems, or factory equipment) removes one historical constraint: “always on” connectivity.
- The exponential growth in the performance and capacity (and mirrored by plummeting costs) of computer hardware and storage devices removes another limit: economies of scale.
- A codification (both formal and de facto) of several design patterns and best practices for describing, invoking, and transmitting information among diverse software systems provided the final piece of the puzzle: API standardization.
Together, these forces have enabled massively scaled cloud platforms. In turn, these platform-as-a-service offerings form the basis of virtualized computing stacks for countless applications across every industry and consumer market. And, yes, a good email API makes it possible to add email to nearly any app and to have some confidence that it just works.
OK, so what does that mean in the real world? Well, it means on the subway home from work, I can open my mobile app and expect to see the exact same data I touched at the office. It means the data I entered in one app get distributed to several other systems without requiring duplicate entry or manually synchronize records. It means the store I just visited doesn’t need to worry about hosting their own infrastructure just to email me a purchase receipt. It all just works, and it’s all in the cloud.
That’s pretty amazing, if you really think about it. And that’s why an email API matters.
How is your day touched by APIs and the cloud? I’d love to hear about it!
By the way, want to learn a little more about the role of an email API and how they’ve changed the way businesses use email? Read “Email Evolved: Why the Cloud and Modern APIs Matter for the Future of Data-Driven Marketing.” And, if you’re wondering why a good email API and cloud architecture makes a difference, check out this blog post Why ESPs Struggle to Deliver Data-Driven Email. (Spoiler: it’s because ESPs aren’t really API-driven.)
As our CTO Alec Peterson wrote on the blog last week, this is an interesting time in the transactional ESP market. Mandrill (operated by MailChimp) recently announced that they were eliminating their stand-alone offering and instead will be incorporated as an add-on feature of MailChimp’s paid, flagship email marketing service.
We have a lot of respect for MailChimp. They’re a great company, and we admire the work they do making full-service email marketing accessible to all kinds of customers. We also understand what their CEO said in his announcement letter about a “fit” issue with the Mandrill product. Transactional email isn’t the business they’re in.
This sort of change always is a hard decision for a company to make. Understanding that not all of Mandrill’s customers have a need for the full-service offering, MailChimp is recommending SparkPost as a Mandrill alternative for developers looking for a transactional email provider.
In fact, SparkPost announced last week a previously-planned change to our pricing structure, notably increasing our free tier to 100,000 free emails per month (as well as incredibly cost-effective rates for higher message volumes). I’m really excited about this pricing model. It’s a win for our customers, and it’s a win for our business model.
These pricing plans mean that SparkPost is matching (and even beating) the rates Mandrill customers have been paying. That’s really good news. But I want to make a further commitment to you today: should the terms of our free tier of pricing ever change in the future, I promise we will nevertheless honor it for any customer currently enrolled at that tier, for the life of that account.
And for anyone who wonders if it’s really possible for SparkPost to keep this promise, the answer, unequivocally, is yes. In his post last week, Alec explained why. I agree with his analysis one-hundred percent.
Giving developers the tools to do great things with transactional email is hard-wired in our DNA. It’s who we are, and our love for developers runs deep—most of us here are developers (or in my case, former developers) ourselves! I’m proud of how our team at SparkPost has risen to the occasion to support the Mandrill developer community, and I’m thrilled we’ve also gotten the pricing part of that right.
Whether you take us up on our 100K free emails per month plan, or a paid level of service, we’d really like to have you as a customer. I look forward to working together to build something awesome.
Hi. I’m Alec Peterson, the CTO at SparkPost. I’ve been building large-scale email infrastructure for a long time—in fact, I’ve been a member of the leadership team here for 10 years. I love this business, and I know how important getting it right is to our customers, including the developers who do such amazing work with our service.
The last few days have been interesting ones in the transactional ESP market. Mandrill (operated by MailChimp) announced that they were making major changes to their offering, including ending their free tier. Shortly afterwards, SparkPost announced a previously-planned change to our pricing structure, notably increasing our free tier to 100k free emails per month.
While we’ve been absolutely thrilled with the response, we did hear from a couple folks who questioned whether it’s really possible for SparkPost to sustainably offer such a significant free tier. The answer, unequivocally, is yes. I’d like to provide a few details on why we can do it, and why SparkPost is uniquely suited to offer this level of free service.
There are a few things that are important to understand about how we do things at SparkPost. Our history is not only in email infrastructure, but also in delivering the highest performance (meaning most efficient) email infrastructure on the planet. That’s not hyperbole. Before we were SparkPost, we were (and, in fact, still are) Message Systems, the leader in on-premises email infrastructure.
Our customers are the most demanding high-volume senders on the planet. We have several on-premises customers who individually send more email than the entire transactional ESP market combined, and they do so using the Momentum platform on just a couple dozen of servers. To service those customers, we’ve had to push the envelope in terms of performance for the entire existence of our company. In other words, building and optimizing email infrastructure that outperforms anything else on the planet is something that we always have done as an organization. And we’re really good at it.
The fact that our cloud infrastructure is built around the de-facto standard for high-performance email is an undeniably powerful position to be in, making all sorts of things possible. Like, for example, offering 100k emails per month for free.
Our deep experience, however, is only part of the story. We’ve also built a remarkable cloud architecture for our service. When we architected SparkPost, we made a strategic decision to build it upon cloud-based, fully virtualized infrastructure, notably Amazon Web Services (AWS). By leveraging AWS, we’re able to forego worrying about managing our own physical plant with buildings, cages, man-traps, security guards, power, generators, UPSs, racks, servers, spare parts, networks, switches and various transit providers. You get the picture. But just as importantly, we have virtually instantaneous access to as much burst capacity as we could ever need—whenever we need it. And what’s more, when we aren’t sending bursting traffic, that elastic capacity goes away and we stop paying for it. That’s the best of both worlds: virtually unlimited capacity, combined with a highly efficient cost model.
Of course, even the most efficient business can’t run without revenue. And while the free plan we just introduced is a great fit for some senders, we also know that for businesses who need a dedicated IP address, or who need to burst beyond 100k/month, one of our paid service tiers is a better solution. In fact, when we crunch the numbers, our conversion percentages and analysis of customer volume overall tell us that we’re making a really sound business decision. Far from being a threat to our business, the 100k/month free plan is, in fact, a business driver that combines a great long-term option for some senders with a fantastic upgrade path for customers looking to grow their email presence even further.
By the way, I want to also point out that we are not in the business of selling data, and do not ever plan to be. We take privacy really seriously. Respecting it is one of our core principles. We understand that a natural reaction to a generous freemium offer is to assume the provider is selling data to outside parties. However, that’s not the case here, and you have our commitment we will not do this. Not now, not ever.
Our business at SparkPost is email infrastructure. We think MailChimp is a great company, and we have a ton of respect for them and the work they do. We also understand and believe what their CEO said in their announcement letter about a “fit” issue with the Mandrill product. Transactional email isn’t the business they’re in. But it’s the fundamental core of our business, and we’re here for the long haul.
Check us out! Whether you take us up on the 100k free emails per month plan, or a paid plan, we’d really like to have you. Our love for developers runs deep. I think you’ll be impressed.