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

mandrill shutdown

TL;DR: All systems are go. Here’s what you need to know to make it through the final countdown and migrate to an alternative before the Mandrill shutdown.

When Mandrill announced that they were shutting down as a stand-alone service and being rolled into MailChimp’s full-service product, a whole lot of developers took to the net to find a Mandrill alternative… and to tell us what they really needed in a developer-focused email delivery service. (Maybe you were one of them!) We listened—on Twitter, Reddit, Github—and took your feedback to heart.

New SparkPost Features to Help Developers Ahead of the Mandrill Shutdown

We knew we already had the core requirements nailed. SparkPost is just a year old, but we’d already built the industry’s highest-performing, scalable, and reliable email delivery service. As a developer-led company, we knew our APIs were a joy to use. (Really! Joy!) So, we were ready to get to work building some of the specific features and tools you and other developers asked for to make handling the Mandrill shutdown and conversion to SparkPost easier. Here are some of the highlights.

  • MST3K Mandrill template converter. This Mandrill template translation tool is a lifesaver. Built by a team of engineers that went to work right away on the issue facing anyone wanting to convert off of Mandrill to SparkPost, this converter intelligently brings templates over from Mandrill to SparkPost. We’ve heard that in some cases this tool has saved around 90% of the time for dev shops to migrate. That’s awesome.
  • Subaccounts. Devs spoke up and said you need subaccounts. We already had subaccounts on our roadmap, but we prioritized it to make life easier for Mandrill refugees. Our engineers went to work and released the first wave of subaccount functionality a few weeks ago. This past week, they released more. We’ve heard some innovative requests, and we’ll be rolling out more functionality around subaccounts in the coming weeks. Developer feedback is the gift that keeps on giving and we appreciate it.
  • CSS inlining. CSS in email really isn’t much fun, and it turns out devs don’t like to deal with the CSS inlining requirements of email. Go figure. They’d rather a tool do that for them so we built them one.
  • Forwarding service. We recently released the sp-forwarding-service for Heroku. It consumes inbound message webhooks and forwards them through SparkPost. It’s so new we haven’t even blogged about it yet! Stay tuned, and we’ll say more about it soon.
  • Suppression list import. Developers who’ve been through a migration before know how important it is to bring over your current suppression lists. Our team wrote a command-line tool that makes it easy to import suppression lists from Mandrilll to SparkPost, without resorting to using the manual web UI.
  • Test mode. There’s no undo when sending email. That’s why a test mode can give peace of mind while coding. You asked, and so we built it.
  • Community Slack. We launched a SparkPost community Slack channel. You showed up. 👋 More devs keep joining. Community members have started helping other community members. We’re in awe of the knowledge and general awesomeness you’ve been sharing in the community channels. Thank you.

And Some Awesome Contributions from the Developer Community

The response from developers has been incredible. We’ve seen you take our platform to another level with your skills and willingness to contribute back to the community. Here’s some of the awesomeness:

I think you can see the pattern of community greatness. These are just a couple examples of many. Many other smart creative devs took on SparkPost for Ruby on Rails (ActionMailer; thanks @dgoerlich!) and SparkPost Python (many devs here… thanks @pegler, @mathiasose, @gnarvaja, @puttu, @svisser, @bartdag to name a few!), extended them, and made them better. There isn’t enough space in this blog post to list everyone that’s made meaningful contributions. Thanks to all these devs!

There’s one more contribution for a quick shout-out:

With just one week left until the scheduled Mandrill shutdown, I wanted to take a breath and thank our developers and users for joining us on this journey. We’re going to keep trying our hardest to build the best and easiest to use cloud email platform, so that you can focus more on building your apps and services.

Your contributions and feedback have made SparkPost even better than before. It’s why we’re so happy to use the hashtag #WeLoveDevelopers. #AndWeDo.

—Josh
@jaberant

 

P.S. Still need to do a last-minute migration to SparkPost before the Mandrill shutdown? We’ve got your back. Check out our Mandrill Migration Survival Guide for the essentials of what you need to make the transition as easy and reliable as possible.

Subaccounts_285x182When Mandrill announced they were doing away with their free tier, many of you looked for new options and we’re proud that we were able to provide a solution for so many members of our community. Through your feedback, we heard that you wanted subaccounts and we’re thrilled to announce that they are now available!

The new subaccounts feature will allow you to support separate business units, mail streams, or customers (if you are an email service provider or consultant) all from within your SparkPost account. Subaccounts enable you to give each of these units direct access to the SparkPost messaging service APIs. (Subaccount users will not have separate access in the UI.) Also note, Heroku users will not be able to use subaccounts.

Subaccounts can be used in a variety of ways depending on your needs. The most common reason to set up subaccounts is to separate assets (such as sending domains and API keys) so that each unit can access/use SparkPost and to separate reporting data. Some common use cases for subaccounts are:

  • You are a service provider for multiple unique customers.
  • You have unique internal business units who operate independently from one another.
  • You have a particular mailstream/campaign that is mission critical and you wish to track and sequester its data separately from other mailstreams/campaigns.

As a Master account owner you only need to give your customer/subaccount user(s) the subaccount API key – they will use it for all operations afforded via the default API key created upon subaccount creation.

For more information on creating, reporting and status details, please check out the subaccount support article.

For future subaccount features, you can check back on the support article for updates or the blog.

Happy Sending!

-Sparky

 

Mandrill Template Migration

In the weeks since MailChimp announced that they have eliminated Mandrill as a stand-alone offering, our team has heard from lots of developers looking for a Mandrill alternative. And, as our lead product manager Amie Durr wrote about subaccounts and other enhanced SparkPost features, it’s been epic feedback that’s really helped us focus on what developers need to be productive.

And near the top of the list is making it easy to import Mandrill templates into SparkPost. That’s something we’ve heard, loud and clear. I sometimes think about email templates like Gollum thought about his ring: precious and powerful, and messing with them can have tricky side effects. Along with branding and structural layout, templates also are shot through with personalization markers—we call them substitution variables, Mandrill says merge tags—that are designed to tailor each recipient’s message with content meant just for them. When you couple that intrinsic complexity with the fact that our respective platforms work differently, you might fear you’ll have a potentially challenging migration task ahead, especially if you have lots of templates.

So, that’s why I’m really happy to announce our newest community project: an open source Mandrill template migration tool that makes it really easy to import Mandrill templates into SparkPost. (Or, as I like to call it, the Mandrill-to-SparkPost Templatizer 3000. That’s MST3K for short ;-).

For the impatient and technically minded, you can just grab the code from GitHub and follow the README. For the more prudent, read on for details about how it works, how to use it, where to get help—and also how you can help out with this project.

Deployment: Where Can I Get MST3K?

First things first: where can you get your hands on the tool?

The Easy Way: Heroku

If you’re developing with Heroku, you can just click this button to deploy MST3K into your Heroku account. Done.

Deploy to Heroku

Once the Heroku deployment completes, you’ll be presented with the web UI.

The Other Way: Run Locally

If you would rather deploy the tool into your own environment, here are the minimal steps. Note: you’ll need to have git  and Node.js 0.12+  installed.


Once the install is complete, you can access the web UI at http://localhost:3000/ .

Whether you deployed in Heroku or locally, the UI will look the same:

 

Mandrill-to-SparkPost Template Tool MST3K UI

How-To: How Do I Use MST3K?

Translating Mandrill Template Content

Once deployed, the simplest way to use the tool is interactively. Choose the “Translate Template Text” option. Paste your Mandrill template code into the left pane of the UI and hit “Translate!” Your translated output will be presented in the right-hand pane, ready to copy-and-paste into SparkPost.

 

Mandrill-to-SparkPost Template Tool MST3K Translation UI

Automating Mandrill Template Migration

Now, one-off, interactive conversions are all well and good, but you might prefer to automatically pull a template from Mandrill, translate it, and upload it directly into your SparkPost account. You probably want the migration to take both the plaintext and HTML template code into account, as well. I got you. Choose the “Migrate a Template” button on the main menu to begin. Here’s how it works:

 

Mandrill-to-SparkPost Template Tool MST3K Migration UI

Mass Mandrill Template Migration

OK, but what if you have lots of templates to migrate all at once? Because the UI is just a presentation layer on top of an API, it can be automated to fit your needs. Here’s an example which uses curl to call the migrate API endpoint directly:


You also can call the /api/translate  endpoint in a similar manner. For much more detail on the API, checkout the README and the code on GitHub.

Capabilities: What Can and Can’t MST3K Do?

So, what template capabilities translate from Mandrill to SparkPost?

If you are unsure of whether your template is migratable, the simplest option might be just to try it: the tool attempts to present useful error messages.

MST3K is designed to translate a Mandrill template that uses Handlebars-style syntax into equivalent SparkPost templates. Here, “Handlebars syntax” means templates that use curly brackets around their variables like this {{firstName}}.

To learn more, or for reference as you read on, it might be helpful to bookmark Mandrill’s Handlebars documentation and SparkPost’s substitutions variables docs. And, the official Handlebars documentation as well. Note that Mandrill has made a few syntax additions which are marked below as “Mandrillisms.”

The rest of the section gives samples of supported Mandrill syntax along with some equivalent SparkPost terminology for reference.

Basic Template Handlebars Syntax

Our MST3K migration tool can translate the basics like this:

Syntax
Mandrill
SparkPost
Variable substitution
Conditional logic
Iteration

Mandrillisms

Mandrill made a few additions to vanilla Handlebars which we can also translate:

Syntax
Mandrill
SparkPost
elseif
Conditional expressions

Inline Helpers

Mandrill has a set of “content formatting helpers” which our migration tool understands but ignores, because there is no equivalent in SparkPost. The helpers currently accepted are the text case conversions: upper , lower , and title . The result post-translation is that those helpers are removed. Here’s an example:

Mandrill
Translated result
{{upper firstName}} {{firstName}}

Unsupported Elements

Finally, there are couple differences between a Mandrill template and a SparkPost template to be aware of when migrating:

  • Inline helpers: the url, date, and striptags helpers have no equivalent in SparkPost.
  • Block helpers: the unless and with block helpers have no equivalent in SparkPost.

MailChimp Template Syntax

By the way, what about MailChimp syntax? Although our support for MailChimp syntax is more limited, we do have early support for MailChimp syntax, thanks to a community contributor. Woot! Our community is pretty epic. Not sure if you’re using Mandrill or MailChimp syntax? Here’s the test: if your templates have {{curly brackets around substitution variables}}, you’re using Mandrill syntax. On the other hand, if you have variables in your template like this:  *|firstName|*, you’re using MailChimp syntax.

Help: Where Can I Learn More about MST3K?

As always, if you run into an issue, you have a how-to question, or you’d like to talk your situation through, come speak to us on SparkPost’s community Slack channel. For template and other code samples, integrations, and more, be sure to check out the SparkPost Developer Hub.

Contributions: How Can I Help Improve MST3K?

As with all community projects, MST3K stands on the shoulders of giants. To help make the tool as awesome as possible, we welcome all contributions from Mandrill and SparkPost users alike. Whether you open an issue, submit a pull request, or come share your experience with the community, we’d love to hear from you.

Let’s Build Something Awesome!

So, there it is: the Mandrill-to-SparkPost Templatizer 3000 is ready to help folks in need of a Mandrill alternative to make it easy to migrate Mandrill templates to SparkPost. I hope this addition to your toolbox serves you well!

—Ewan

Biz Eval Guide Blog Footer

 

We’re adding some great features to help developers looking for a Mandrill alternative. Spoiler: subaccounts are here.

orange we heart developers banner twitter awards

** 3/31/2016 – Update: Subaccounts are now live! Further detail here.

A Feedback Frenzy: How You’re Helping to Make SparkPost Better

Wow. It’s been an amazing month of hard work for the product team here at SparkPost. And I know I’m not the only one keeping my caffeinated drink of choice flowing (through an IV drip, if necessary. Diet Coke girl, here BTW).

We’ve always worked to make SparkPost the most awesome email delivery service, period. And we hear from developers and other customers with product feedback pretty often. But, in the wake of MailChimp’s decision to stop offering their Mandrill product as a stand-alone offering (and endorsing SparkPost as a Mandrill alternative for developers), our Twitter and community Slack channels have been flooded with feedback, feature requests, praise, and yes, even constructive criticism. And we’ve tracked, discussed, and prioritized every single one. In fact, if you’ve given us product feedback, you’re likely to have seen one of our product managers or engineers reach back out for additional insight on the pains, challenges, and use cases you’re trying to solve.

This type and volume of feedback is every product manager’s dream come true, and I want you to know that we’re giving your feedback the care and attention it deserves. That’s just how we work. For over 15 years, our team has lived and breathed the belief that partnering with our customers to drive innovation and excellence in messaging is the right thing to do.

Now, that’s not to say we’re going to implement every feature or make every change that’s asked of us. A big part of my job is to take a hard look at requests to ensure they:

  • Help developers integrate our service easily… and make it possible to really innovate with email;
  • Meet the functional needs of the current and future markets we serve; and
  • Are aligned with our goals and values as a company, as well as the best practices in the email and tech industries.

This perfect storm of feedback could have become really overwhelming, really quickly. Fortunately, we’re big believers in agile development practices. And, as an agile company, leveraging a mix of Scrum and Kanban, we’re pretty darn good at knocking out small wins while also working to implement more complex or comprehensive improvements. We’re also huge fans of iterating on features—allowing our customers to get started using a feature, sooner rather than later. Once a feature or improvement is released, we capture feedback on how it works in the real world, and what could use a little tweaking, and continue to iterate from there.

As a product manager, It’s been gratifying to me to see how well the agile development practices really work, even (or perhaps especially!) at the pace that we’ve been working over this past month.

Here’s the New SparkPost Goodness

So: what have we done in the last couple of weeks? A lot! Without further ado, I’ll summarize some of new SparkPost highlights of the past month:

  • We got the pricing right: Check out what we’re doing with SparkPost’s pricing
  • Test Mode: The ability to test your integration before moving it to production, without the fear of sending to real live customers! We’ve also heard requests to support test-only API keys and webhooks—it’s definitely on our radar. Learn more about SparkPost’s new test mode.
  • CSS Inliner: To ensure that your email looks the same across the wide proliferation of inboxes (particularly with the…quirks… of Gmail), it’s a good practice to inline your CSS by removing it from a <style> block and putting it directly into each HTML attribute. That can be extremely painful and honestly, ain’t nobody got time for that. Put some fun back in your day and let us handle this task for you. Learn more about CSS inlining with SparkPost.
  • Mandrill Template Converter: Our template guru Ewan Dennis recently wrote some preliminary tips for manually translating Mandrill templates for SparkPost. Now, he’s working on an automated tool to make it even easier. The tool is still in… let’s call it beta, but if you want early access (and are willing to do some real-world testing), he’d love to have you. Join the SparkPost community Slack and ask for @edennis. He’ll give you the good stuff. **Update: the Mandrill-to-SparkPost template tool is live! Check out Ewan’s latest post about where to get it and how to use the tool to convert and migrate your Mandrill templates.
  • WordPress Plugin: We’re continuing to evolve this plugin by adding support for API over SMTP for people that are blocked for ports 587/2525, template selection, and to allow tracking to be toggled on/off from the plugin. Have more ideas? Please share them! Learn more about SparkPost’s WordPress plugin.
  • C# Client Lib: This one makes our heart swell because it came from a community member! Thank you thank you! Check out the community-developed SparkPost C# library.
  • Run SparkPost in Postman: SparkPost is an API-first service, because we love developers. And because it’s the best way to innovate with email. It’s that simple. What this means in practice is that we build our APIs (you guessed it) first, and then build our UI using those same API calls. Having said that, we also love our UI, and there are plenty of SparkPost users who’d rather not use a cURL command line or dig into the details of HTTP to build their API requests. This is where Postman comes in, turning an API request and response into something much more human-readable. Learn more about running SparkPost in Postman.
  • Slack community: where our teams are available for real time feedback on integration support, best practices, and developer love. Also? We’ve just uploaded all of our favorite emojis. It’s amazing what a little :homerbush: can do for your mood. Join the SparkPost community Slack team.

Oh, and One More Thing: Subaccounts! 

Of all the requests we’ve received over the last several weeks, by far the one raised most frequently is for “Subaccounts.” Fortunately, we were already well underway in terms of R&D for this feature, and we were able to shift some other priorities around in order to focus on bringing this to market ahead of the Mandrill cutover on April 27.

Before getting into any of the details, let me answer the most frequent one: “When?”

** 3/31/2016 – Update: Subaccounts are live! This initial launch will be closely followed with additional feature updates throughout the month of April, with all of the core components in place by the week of April 20. We know that this timing will make it tight for some customers who currently rely on Mandrill’s subaccount features. So, here’s what we’re doing:

  • We’ve already updated the API and SMTP documentation to include the subaccounts components, so you can start preparing immediately. The subaccounts API and SMTP documentation lives in our Developer Hub.
  • A comprehensive knowledge base article will be available within a few days that will outline use cases, implementation specifics, how-to’s,; and a host of future enhancements we’re already focused on.
  • Our awesome team is available on Slack to help answer any integration questions you may have.

What all of this means is that you don’t need to wait for the Mandrill cut-off date to get started with your migration. You can open a SparkPost account now, begin your integration, and familiarize yourself with the features and resources that are already available. By following these steps you can be up and running with subaccounts prior to the April 27 Mandrill cut-off date.

Some more details on subaccounts:

  • Subaccounts will be available on all pricing plans, including free. There will be no additional charge associated with subaccounts.
  • Both the UI and our APIs have support for subaccounts features, though some areas of the UI and API will not be supported fully at launch.
  • The first launch in early April will provide subaccount support for the following features:
    • Metrics API (Not available for subaccount API keys)
    • Message Events API
    • Sending Domains API
    • Tracking Domains API
    • Suppression List API
    • SMTP API
  • Following closely behind the initial launch (but before the Mandrill cut-over) will be subaccount support for:
    • Transmission API
    • Custom Tracking Domains
    • And more!

In addition to subaccounts, we’re actively underway with providing customers the ability to have multiple dedicated IPs per account, as well as the ability to manage those IPs for your subaccounts. More to come on those items in the next couple weeks as well.

Thank You, and Please Keep Your Feedback Coming! 

I want to acknowledge personally how valuable the feedback of our growing developer community has been in helping us to prioritize and accelerate many of these new SparkPost features.

To everyone who has taken the time to reach out to us, please accept my genuine thanks and appreciation. It’s people like you, sharing the good and the bad, that are helping us make SparkPost an even more amazing service for everyone. You rock. I’m reminded every day why I love the developer community.

If you haven’t joined in the conversation yet, please do! I’d love to hear from you on Twitter @AmieDurr. And now, you also can find me in our community slack.

-Amie Durr
VP Product Management

** 3/31/2016 – Update: Subaccounts now live! Further detail can be found here.

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