- Developer Hub
- SparkPost API
- Email Tools
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Deliverability Guide
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Contact Us
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.)
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. 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.
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 free developer 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.
—PhillipSparkPost © 2018 All Rights Reserved