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

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.

—Phillip

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