Community Pull Requests Blog Gears Collaboration

How Community Pull Requests have made migrating from Mandrill to SparkPost smooth

The last two months have been a rush! As the community manager here at SparkPost, a large part of my job falls into the hard to measure categories of brand awareness and garnering feedback from the community. This is usually what they call a long-tail endeavor — something that you don’t expect to see dramatic results from immediately. Until, that is, something upheaves the industry.

This is every community manager’s dream — what we were made to do! I refilled my coffee mug, rallied the troops (most of whom were already online), and we took up the banner of answering questions, pointing people to resources, and burning the midnight oil helping out developers who were left treading water in the wake of the news.

You all came out of the woodwork suggesting feature requests, offering feedback, giving us new use cases, and in general being awesome. We hope that you’ve seen us respond in kind with our wholehearted appreciation and support, and occasionally a t-shirt or sticker thrown in.

If you’ve missed the recent digests with everything we’ve pushed out in the last few months, check out what Amie Durr and Josh Aberant have to say. But we aren’t stopping there! We’re still prioritizing new feature requests, building new tools, accepting pull requests, and more, as well as having daily conversations with you all in our Slack channel.

We know you’ve been busy as well. We know this because we’ve watched you pull together as a community, build resources to help each other out, answer each other’s questions, and submit pull request after pull request after pull request after pull request after… well, you get the idea.

lucy-chocolates

On behalf of myself and all of us at SparkPost, thank you, thank you, thank you! All of your pull requests, contributions, feedback, support, and encouragement have meant the world to us. Your feedback is directly affecting our decisions, priorities, and direction as a company. After all — you’re the ones using the product! It’s been a crazy ride so far (and we know it’s not over yet!), but messages like these have kept us going, and warmed my community-loving heart:

In short, we ♥ developers and we ♥ you. We’re all in it to make SparkPost the best possible service for our customers. And while the last 2 months have been full of all sorts of exciting developments, keep your fork — the best is yet to come! Also, if someone wants to invent an IV coffee machine and send us a prototype, I don’t think anyone would complain 😉

-Mary

Biz Eval Guide Blog Footer

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.

—Phillip

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. 

— Alec

mandrill alternative

Surprised by news from Mandrill? We understand how frustrating that can be, and we have a Mandrill alternative for you. If you want to get started with SparkPost fast, our developer community has got you covered! Here’s a quick guide to getting started and getting your transactional emails up and running.

TL;DR

  1. Create a SparkPost account
  2. Configure sending domains, DKIM, and SPF
  3. Migrate to the SparkPost API
  4. Migrate your templates
  5. Build something awesome

1. Create a SparkPost Account

First, sign up for a free SparkPost account if you haven’t already. BTW, we’ve made the pricing really easy: up to 100,000 emails/month for free.

2. Configure Sending Domains, DKIM, and SPF

Check out our Getting Started Walkthrough video for an easy quick start. If video’s not your thing, simply follow the in-app SparkPost dashboard as it walks you through the basic account configuration steps.

3. Migrate to the SparkPost API

SparkPost’s API is fantastic. Here’s the API documentation. As a general rule, if you see it in our UI, you can access it in our API, too.

API Clients

Just want to get your hands in some code? You’ll find client libraries for the usual suspects on GitHub (and maybe some unusual ones, too):

Basic Concepts

Sending: Transmissions

The Transmissions endpoint is the business end of SparkPost’s email sending capability. It supports both transactional and non-transactional mail streams, templating, tracking, variable substitution, attachments and all the usual goodies. It’s documented here with sample code in all the usual languages.

Sending: SMTP

You can also use traditional SMTP to inject your mail into SparkPost. Here’s an intro video and documentation for the readers.

Receiving: Relay Webhooks

On the inbound side, you can use our Relay Webhooks along with Inbound Domains to accept inbound mail.

Tracking: Webhooks and Message Events

Beyond delivery and receipt, you can use Webhooks or the Message Events endpoint keep track of deliveries, bounces, opens, clicks, and all the other events SparkPost emits.

BTW, here’s a definitive reference to the available events.

Translating Mandrill to SparkPost Terminology

Mandrill and SparkPost use slightly different nomenclature to describe similar functions. Here’s a SparkPost terminology primer for those coming from Mandrill’s API.

Mandrill Says
SparkPost Says
Notes
merge vars substitution data SparkPost’s substitution data is similar to Mandrill’s with rich JSON-like structure.
messages/search-time-series metrics SparkPost Metrics offer time-series aggregate views on everything to do with your mail streams. They also power the reporting UI.

messages/send

messages/send-template

messages/send-raw

transmissions A single endpoint for all types of transmission.

 4. Migrate Your Templates

**Update: we have an awesome new Mandrill-to-SparkPost template migration tool! Now, it’s even easier to get started with SparkPost as a Mandrill alternative. If that sounds good to you, go get it and read how to use the tool to convert and migrate your Mandrill templates.

Like Mandrill, SparkPost’s templates use a handlebars-like syntax with {{braces}}  surrounding variables.  You can edit templates in the SparkPost UI or directly using the templates API endpoint.

If you’re just pulling variables into your template for simple personalization, you might be able to use your Mandrill templates unchanged with SparkPost.  Otherwise, here are a few syntax pointers.

Feature
Mandrill Syntax
SparkPost Syntax
conditions
loops
nested variables
variables

5. Build Something Awesome

Support Resources

  • General help: You can find help with most questions about SparkPost functionality, account configuration, and our web app in the SparkPost Support Center.
  • Developer stuff: For help with code and general developer support, the SparkPost Developer Hub is a great resource. And, if you want to chat something through with our developer community team, join our Slack community.

Integrations

–Ewan