- Developer Hub
- SparkPost API
- Free Tools for Email Teams and Developers
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Email Deliverability Resources
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Customers Stories
- Contact Us
As a Sales Engineer at SparkPost, I have a lot of discussions with prospects that represent software platforms which send emails on behalf of their customers. These include a variety of applications from your typical Email Service Providers (ESP), CRM platforms for various verticals, any sales automation systems and platforms that support healthcare and various non-profits. One of the central questions I get is how they can share a group of standard templates with their clients? While the answer is not very difficult, it always seems to lead to a bunch of hand-waving and list of definitions of the customer’s terms. While I expect to have many of those discussions moving forward, I thought I would write this blog in order to shed some light on the subject.
Ok, let’s start with the ground rules:
- Each SparkPost account has ONE master account. The company paying SparkPost is typically the owner of that master account.
- The SparkPost account can then have many subaccounts. Subaccounts are usually either company departments that want to keep email sending separate from one another or clients that are sending email through your platform.
- Templates are emails that can be stored in the SparkPost platform for later use, and typically allow for substitution data to be injected into the email just before sending. They don’t have to be stored on the SparkPost platform to be used, but for this discussion they do. It’s also important to understand these rules around templates:
- Templates created by a subaccount are owned by the subaccount and can only be edited by the subaccount.
- Templates created by the master account can be one of these three states:
- Owned and only seen by the master account.
- Can be given to a subaccount which then allows that subaccount to edit that template as if they created the template. This also means that the master account loses the ability to make changes to that template.
- Can share the template with all subaccounts. This gives all subaccounts the ability to read/use the template but can not make changes to the template. If the master account makes an edit to the template, all subaccounts will see those edits.
The typical scenario is easy enough; The the master account wants the ability to share a template or a set of templates with a specific subaccount or all subaccounts. The way to do this in SparkPost is for the master account to select which template they want to share, then duplicate that template and give it to the subaccount.
To get here, I selected the specific template from within the SparkPost UI and pressed the duplicate link/action. It then presented me with the template along with several input fields, one of them being how I want to assign the template. I picked, ‘Assign to Subaccounts’ then entered in ‘Mr Pickles Sandwiches’ as the target subaccount. Once I save this template, Mr Pickles Sandwiches will then have sole ownership of the template. I would then do this process for each template. The SparkPost ‘template’ API would allow me to automate this process if I created a small app that read a targeted list of stored templates for sharing, looped through each template name to read a copy of each template, then created a new template using the subaccounts name in the subaccount field.
The other scenario is when the master account wants to share the template with all of the subaccounts. This is very simple. When creating the template, the user simply needs to select, the ‘Share with all subaccounts’ radio button (shown in the picture above). That now gives all current and new subaccounts the ability to read/use that template. There again, the template can be brought into SparkPost via the ‘template’ API and the option for sharing can be turned on at that time allowing for a fully automated process.
Questions on templates or subaccounts? You can check out our documentation above or ping us in our community slack channel.
Data, Data, Data!
Imagine this: you’re an email service provider; or built an app that sends on behalf of other businesses; or a group within a larger company managing email on behalf of several divisions or brands. You connect to SparkPost, you set up subaccounts for each of your customers/divisions/brands, you send your email, and then . . . you confront the firehose of data that comes with webhook events for all those constituents. It’s a lot of data to consume. And a lot of data to separate for the relevant audiences.
Never fear, we’ve heard your cry. We actually have 2 enhancements that help those of you sending on behalf of others:
The first thing is that a single SparkPost account can now have multiple custom bounce (sometimes known as return-path domains.) This enhancement went in a couple of weeks ago. Previously, a single SparkPost account could only have 1 custom bounce domain. This knowledge base article describes how to create them and why doing so improves your deliverability. For senders with multiple customers, you can set a bounce domain for each of your customers or brands, create a default for the account, and specify which one your want to use in the transmission API call.
- Helpful hint: DO NOT use the UI to create multiple bounce domains. The UI has not yet been updated for the new functionality. That’s in the works. As we are an API-first company, we pushed the API update first, while we work to update the UI.
The second big enhancement is that you can now create separate webhook endpoints for each subaccount. This way, rather than getting ALL your account delivery and engagement data at one endpoint and having to filter out different subaccounts, you can create separate endpoints for each subaccount and pipe the relevant data to the right place. Here’s the article on subaccounts – updated for the new webhooks functionality.
Some helpful hints:
- If you want to receive data for multiple (but not all) subaccounts at a single end-point, you can give the same endpoint to multiple subaccounts.
- If you want to receive data for just the master account (for example, if you only use your subaccount for testing and want to filter the test data out), enter “master” into the UI where you create your webhook. If you don’t enter anything into the subaccount field, you will get all data for the master and all subaccounts — current functionality.
Try It Out
Multiple bounce domains for a single account and webhooks by subaccount were two of the most requested features among our entire customer base — big and small. We listened and added these enhancements. Try them out and let us know what you think.
Amie, Nichelle, Irina
-SparkPost Product Team
Top 10 Blogs: Our Year in Review
We’re finishing out the year with a roundup of our top 10 blogs from 2016. The Mandrill announcement in April impacted our community, and as a result our blog, in a big way. We’re recapping that along with other top posts on deliverability tips and email marketing best practices down below. As always, our ears are open, so if there’s a certain topic you’d like to see on the blog, leave us a comment, tweet us, or ping us in slack.
Without further ado, we give you the top 10 blogs of 2016:
It’s no surprise that our Mandrill alternative blogs dominated our top 10 list (5 out of our top 10). We responded in real-time to the Mandrill crisis, and our CEO even weighed in and made you a promise he intends to stick by for the long haul. The Mandrill incident also inspired us to create SendGrid and Mailgun migration guides, check them out when you have a chance.
But beyond Mandrill, we also had some other top posts. Coming in second was using SparkPost in PHP. Believe it or not, many of you use PHP through our WordPress plugin.
For developers who want to get the most out of SparkPost templating capabilities, this post was meant for you! In this straight-forward post, Chris Wilson makes sending email easy and gives you some pro tips along the way.
Everyone wants to know how to interview well. In this post we told you about what four tech recruiters look for when hiring developer and engineering candidates.
One of the most useful elements of SparkPost are our webhooks and in this post, Ewan Dennis walks you through the basics and beyond. Knowing what to expect functionally beyond the raw API spec is half the battle when consuming new data sources like SparkPost webhooks.
The Outlook inbox is one of the major destinations for most email senders, especially those with large numbers of consumer subscribers. It also has a reputation for being somewhat tricky to get into. In this post, one of our deliverability experts, Tonya Gordon, shares what senders need to know in order to get the best Hotmail/Outlook deliverability and ensure their messages reach the inbox.
Thanks to your feedback, the Mandrill event helped us expedite our release of subaccounts ahead of schedule. Our VP of Product told you about how we process your feedback and what’s available with subaccounts.
Sometimes you need to go beyond a top 10 list and in this case we did — 17 tips on how not to be labeled an email rookie. In this post we put together a list of common mistakes, with a heavy dose of snark, on how to avoid being labeled an email marketing rookie.
Do you know what the lowest e-commerce order generators are? In this post, we give you five tips and stats for mastering retail marketing. From social media, to mobile and beacon triggered emails.
You know you need to send email, but you don’t want to spend a lot of time or effort on it — you just want something that works out of the box. It’s not too much to ask! Many frameworks, languages, and tools come with SMTP support, but the last step is the most important – an SMTP server. In this post, we walk you through how to set up SparkPost as your SMTP Relay.
And that rounds out our Top 10 Blogs for 2016! Any industry trends or topics you think were under-represented? Leave us a comment below, or tweet us!
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:
- C# library. We hadn’t yet built a SparkPost C# library, but @darrencauthon on Github needed one. So, he built it and contributed it to the community.
- Drupal module. Github user @zaporylie wanted to use a SparkPost Drupal module, so he built one and gave it back it to the community.
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:
- Dev Chris Pitt felt there should be some video examples of programming SparkPost, so he created a set of walk-through videos. Thanks Chris, this is amazing. We heard from other users just how helpful your videos are!
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.
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.
When 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.
We’re adding some great features to help developers looking for a Mandrill alternative. Spoiler: subaccounts are 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.
VP Product ManagementSparkPost © 2018 All Rights Reserved