The Best in Email: 2017 Sparky Award Winners

How about that Oscars ending last Sunday? While the Sparky Awards don’t have nearly as dramatic of a twist, we are very excited to share the 2017 Sparky Award winners with you and recognize some seriously awesome efforts in the email space.

As word got out about the second annual Sparky Awards, our submissions nearly quadrupled in volume from last year. Our judges pored over nominations and eventually narrowed it down to a field of 2 top entries in each category and deliberated over the final category winners. Turns out you can have some fun with transactional emails, get super creative with subject line testing to gather data, AND solve important real-world problems with our API.

Without further ado, here are our 2017 Sparky Award winners:

Best Subject Line

Winner: Evite
Subject Line: Are you kitten me right meow?
Submission Recap: This email announced the launch of Evite’s new invitation category, “Pet Parties”. Evite had no data on which of their users were interested in pets, so the team needed an engaging subject line that would entice a broad group of users to open. They conducted a 10/10/80 A/B split test on the tone of the subject and message: Playful vs. Traditional announcement. The ultimate subject line for this email, “Are you kitten me right meow?”, had an open rate 2x higher than average. The then-proven “Playful” tone set the precedent for high open rates and engaging copy throughout the rest of Evite’s summer campaign

Best Transactional Email

Winner: Zillow
Submission Recap: Looking to increase engagement on favorited homes, users are sent an email with dynamic up-to-the-time-of-send stats on a favorited home (views & listings) within 24 hours of favoriting. More than 2 saves within 24 hours are batched into a digest version. There are many interaction points in the email – clickable images, links and multiple category buttons per image. Surfacing the number of people who have also viewed and saved that same home introduced an element of transparency (whether or not the home was popular) as well as competition (Be the First to See it!)

Best Use of the SparkPost API

Winner: Audio Images International, Inc.
Submission Recap: AIII operates a full-service multi-tenant messaging system specifically targeting property managers. SparkPost powers the fully integrated messaging service, complementing their best-in-class automated answering service. AIII’s focus is on empowering property managers to send timely and targeted communication to their hundreds of residents. Messages can be sent to individual units, or to an entire building. Residents receive messages in their format of choice, whether that’s html / text email, a text message, or both. AIII then processes webhook event data from SparkPost to let their customers, the property managers, know when they might have a typo’d email address (hard bounce), or what percent of residents interacted with the message (open and/or click). Their preference center and webhook-driven reporting make them stand out as a great use of the SparkPost API.

Grand Prize

The grand prize 2017 Sparky Award winner and recipient of up to $1000 in cash toward an industry conference is… Audio Images International, Inc!

Congratulations to all of the winners, you’ll all be receiving an engraved 2017 Sparky Award with your company name & category!

And special thanks to our judges: Dan Levinson, Clea Moore, Dave Gray & Celebrity Guest Judge Jack Wrigley.

-Jen

Thoughts on the Sparky Awards or email in general? Leave us a comment below or tweet us.

Architecting-Reporting_Dev-Blog_600x300_0716 (1)

At SparkPost we send over 25% of all non-spam email, but how do we account for all of those messages? Humans! Our well-equipped team calculates over 40 metrics and gives you the ability to dissect it in any way. Well, that was our first stab at this capability but we quickly realized it was too much work for them to do. Joking aside, scalable reporting is a challenging problem because we have to process millions of events per minute and ensure they can be queried within a timely manner. I hope to explain in some detail how we’ve solved this problem.

Sending email is great and we tell you we’re the best email service out there. However, if you’re like me, you need some hard evidence of this claim. You may not realize it but there’s a lot that happens when sending an email: Momentum (our email engine) receives a message (injection), the ISP receives it (delivery), the recipient’s mailbox is full (soft bounce), and so on. Seeing this at the 10,000-foot glance is great for reporting back to your boss, but you’ll also need to diagnose problems by inspecting the lifecycle of one message. We have solutions for both. And the architectural designs we made allow us to easily add different uses of this data. We implemented a strategy called ETL (extract, transform and load). This pattern is what powers Metrics, Message Events, Webhooks and Suppressions. I’ll walk you through this process starting with the Event Hose.

Event Hose

The event hose is responsible for keeping track of all the different events that can occur during the course of sending messages (injection, delivery, bounce, rejection, etc.). It logs these events as they occur in JSON to an exchange in RabbitMQ. By offloading the queuing of these events from Momentum, it provides a good separation and allows our operations team to scale this cluster of servers independently. If you are familiar with the pub-sub model, the event hose acts as the publisher. However, without subscribers, these messages would float into the ether. What are our subscribers and how do they work you ask? Read on!

Metrics ETL

The Metrics ETL is the first of a collection of subscribers in this stack. It is a clustered Node.js process that binds to a RabbitMQ queue. This process receives messages from the queue as they are emitted and batches them up by transforming the data to adhere to the schema within a database called Vertica.

Message Events ETL

Like the Metrics ETL this is a clustered Node.js process. However, it binds to a different queue and has its own independent control over processing the data. It also loads into Vertica but into a more flexible schema called a flex table. Think of it as MongoDB on steroids. As mentioned in the intro, there are other uses of this data that I will not get into today. If you use webhooks or suppressions, it has different processes and logic to process this data.

Vertica

We spent a great deal of time vetting analytic database solutions to fit our many different use cases. The big advantage are projections, similar to a materialized views, which provide the ability to store raw event data and model very complex queries for all the different ad-hoc drill downs and groupings (domain, time series, sending pool, etc). Lastly, it is horizontally scalable and allows us to easily add new nodes as our load and data set increases.

HTTP API Layer

As the processes I described above loads the data, users can retrieve data from several API endpoints. As explained in How SparkPost Built the Best Email API for Developers, we use RESTful web APIs. The Metrics API provides a variety of endpoints enabling you to retrieve a summary of the data, data grouped by a specific qualifier, or data by event type. This means I can see statistics about my emails at an aggregate level, by a time range, grouped by domain, subaccount, IP pool, sending domain, etc. The capabilities are extensive and our users love the different dissections of the data they can retrieve in almost real-time. We retain this information for six month to allow for trending of the data over time. If you need the data longer than that, we encourage you to set up a webhook and load the data into their respective business intelligence tools.

The Message Events API allows a user to search on the raw events the event hose logs above. The retention of these events is 10 days, and is intended for more immediate debugging of your messages (push, email, etc).

Web User Interface

We built SparkPost for the developer first but we understand that not all of our users are technical. We provide a Reports UI that allows a user to drill down by many different facets like: a recipient domain, sending domain, ip pool and campaign. It is built using the same APIs mentioned above.

Conclusion

I hope this shed some light on how SparkPost processes the large amount of data and makes it available to you. We’re also currently working on re-architecting everything I just talked about. We’ve learned a lot over the first 18 months of SparkPost, especially managing many different tiers of our own infrastructure. I’ve personally spent many hours triaging and fighting fires around RabbitMQ and Vertica. We have decided to leverage a service based message queue in SQS, and are starting to investigate service-based alternatives to Vertica. I plan on writing a follow up to this later in the year, so stay tuned!

Our knowledgeable staff also uses this data to ensure you’re making the best decisions when sending your messages with SparkPost. I encourage you to start using these APIs and the WebUI to start digging into how your messages are performing. It can also be crucial if you get stuck in one of those Lumbergh moments and have to provide an email report to your boss by 5pm on a Friday, or need to dig into why an ISP is bouncing your email. We’ve also seen great uses of our APIs in hackathon projects. So get creative and let us help you build something awesome.

–Bob Evans, Director of Engineering

How-SparkPost-Built-An-Email-API_Dev-Blog_600x300_0716

Using community feedback to build the best email API

Steve Jobs once said, “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple.” This is certainly true when it comes to building a simple and easy-to-use API, which for SparkPost is the primary user interface that developers interact with. So how did we create the best email API that developers love? Read on to learn some tips from the SparkPost Engineering team.

RESTful Architecture

One of our first decisions was to adopt a RESTful architectural style. Representational state transfer (REST) based web APIs have been used since the early 2000s. In the last several years, it has become the de-facto standard of cloud APIs. RESTful APIs, including the SparkPost API, has a collection of resources (https://api.sparkpost.com/api/v1/sending-domains/mydomain.com for example). These resources, described using JSON, allow clients to interact with it over the network using the standard HTTP verbs (GET, POST, PUT, DELETE), and get standard HTTP response codes (200, 500, 400, etc ) back.

The RESTful architecture style improves the simplicity, portability, interoperability, and modifiability of an API. Using HTTP and JSON makes it easy for developers, regardless of which programming language they use – PHP, Ruby, and Java – to integrate with our API without knowing our underlying technology. Other styles that were more common in the past like SOAP and JSON-RPC are generally obsolete. Today, more developer-friendly RESTful APIs replace them.

API Governance

Important as it is to decide on an architectural style, there are many choices to make when implementing the API’s interface. Oscar Wilde once said, “consistency is the last refuge of the unimaginative,” but if your choices are not a consistent set of conventions, then the API will be very hard to understand and use. At SparkPost, we have multiple teams working on different parts of our API. Within those teams, people work on different APIs at different times. Therefore, it’s very important that our API is consistent in the use of conventions. To achieve this, we established a governance group including a few engineers representing each team and a member of the Product Management team. This group is responsible for establishing, documenting, and enforcing our API conventions across all teams.

API First

We made a decision early on that our entire application would be built “API first.” This means that we did not bolt on our APIs to the application after the fact – the APIs are the application. Even our web user interface uses the APIs. It’s a client-side Javascript application which makes calls against the same APIs developers integrate directly against. This sometimes means that we build and publicize the API even before there is equivalent functionality in the web UI. To bridge that gap, we provide Postman collections for all our APIs so you can easily interact with all the functionality they provide.

Documentation First

When we build a new API endpoint or enhance an existing one, we always document and peer review changes first before a single line of code is written. This approach helps enforce our conventions, keeps things consistent, and ensures the API is very user friendly. It also cuts down on the amount of rework, bugs, and breaking changes. We use an API documentation markdown language called API Blueprint and manage our docs in Github. We encourage our community to contribute and improve upon these open source docs. Initially, we published our docs to Apiary, a great tool for prototyping and publishing API docs. However, embedding Apiary into our website doesn’t work on mobile devices so we now use Jekyll to generate static docs. Eventually, we may switch over to Swagger (now Open API) as the markdown format since this new standard continues to gain traction.

Technical Excellence and Transparency

We have a strong engineering culture and are proud of what we build. It is not sufficient to just have an idea for a great API. We need to build APIs quickly, iterate on them rapidly, and verify that they’re reliable and stable. For this reason, we embrace Continuous Delivery methodologies so that we can make changes and deploy them quickly and reliably. It is important to developers that we provide a rock solid service.

We peer review all API code changes, run them through unit and functional tests, periodic performance tests, and automatically deploy and smoke test them. We roll back changes automatically without impacting our users if any failures are detected. We also have extensive monitoring using a variety of tools including Circonus and OpsGenie. Thanks to these tools, we are immediately alerted when there are availability issues that need attention. When production issues affecting customers arise, we can respond quickly since we have engineers on-call 24/7. We also use our Status Page to keep our developer community updated.

Listen and Respond to the Developer Community

When we first released our API, it was quite minimal, supporting the most important features of sending email via API and SMTP as well as some reporting with the Metrics API. We collected feedback through customer interviews, user testing, surveys, and developer conferences early on. Members of our developer community recently sent us a lot of feedback on our Slack channel, which we launched in response to the Mandrill announcement. Subaccount support and IP pool management and our developer friendly freemium pricing are examples of improvements to the API in response to developer feedback, and on a weekly basis we make many improvements based on suggestions from the community.

Developer Relations

We have a small team of developer advocates that focus on listening to developers and improving the developer experience. This team helps maintain our API docs, client libraries, and community Slack channel. In addition, they attend and sponsor developer meet-ups like CharmCityJS, hackathons such as Bitcamp, and conferences including Fluent. This team also acts as internal advocates for the developer community and helps drive improvements across the service including the APIs and our support process. Beyond the small team, we have many who contribute on a part-time basis to the developer relations mission.

APIs Are For Integration

While RESTful APIs are easy to integrate against with any language, it is very convenient to have a client library that you can use to get up and running quickly. We are proud of the wide range of client libraries and integrations available for SparkPost. These include Node.js, Java, Go, Python, and others listed on our Developer Hub. We also have integrations for WordPress, Zapier, Heroku, and have several community contributed libraries for Ruby and C#.

Versioning and No Breaking Changes

We released v1 of our API, with the public beta of SparkPost, upon two deliberate decisions. The first is that versioning will be in the URI rather than as a header. This is easier than requiring an API or schema version to passed in as a header. Secondly, by explicitly putting the version into the URI, we committed to no breaking changes to the API. Breaking changes occur when the behavior of an API call changes, which breaks a customer’s integration. We take this seriously and prevent them through code reviews and automated tests. However, we can and do extend the API by adding new endpoints, parameters and inputs, and response values. Will we ever need a v2 of the API? Perhaps down the road when we wish to change the whole semantics for the API. However, we don’t foresee a need for that soon.

Don’t Forget About SMTP

We know that most developers still like the ease and portability of using SMTP to send their transactional or marketing email. Therefore, we added the ability to have much of the same functionality over SMTP as you have with the RESTful API. The X-MSYS-API header allows you to pass in campaign, meta data, and control data such as turning on engagement tracking or setting the IP Pool. The SMTP API also supports subaccounts.

 

I hope you learned a few things from how SparkPost built the best email API that developers love. Take what you learned and apply it to your own API development. Do you love building awesome APIs? Come join us, we are always hiring.  If you have any questions or comments please mention us on Twitter or find us on our community Slack channel.

—Chris McFadden, VP Engineering

SMTP Relay Graphic Cloud Monitor

 

Note: If you’re using SMTP to route all of your personal mail through SparkPost, awesome! However, be sure to use an email address with a different sending domain (not one associated with your SparkPost account) for your account login. That way, if you ever run into any issues, you’re still able to contact us for help.

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. SparkPost fills that need with SMTP support and a simple setup process.

Today, I’ll be demonstrating how to set up an SMTP relay, so you can use your own email client to send emails from your personal domain. I’ll be using Gmail as my email client, and shopwithkindness.org as my sending domain.

Let’s get started!

How to Setup SparkPost as your SMTP Relay

There are a few things you’ll need before setting up an SMTP relay.

  1. A verified sending domain.
  2. An API key with the “Send via SMTP” permission enabled.
  3. An e-mail client or service which allows you to enable SparkPost as your SMTP relay.

For this walkthrough, I’ll be using Gmail. To begin, navigate to the settings.

navigate to the settings button smtp relay

From there, click on the “Accounts” tab.

click on the accounts tab smtp relay how to

Next, click on “Add another email address you own”.

add another email address you own smtp relay how to

In the pop-up menu, enter the (verified) email address and press next. I’d like to be able to send with “vincent@shopwithkindness.org”, so that’s what I type in.

enter the email address you'd like to use smtp relay how to

Then, enter “smtp.sparkpostmail.com” as the SMTP Server,“SMTP_Injection” as the username, and 587 as the port. Your password should be your API key with “Send via SMTP” enabled. This information can be found under Account -> SMTP Relay in your SparkPost dashboard.

enter your username and port smtp relay how to

 

Let’s get started!

Lastly, you’ll need to login to your inbox to confirm. After that, we’re done! Time to send some Shop With Kindness emails.

Other Resources

If it turns out that SMTP isn’t the right email solution for you, consider taking advantage of the SparkPost API. The API has many pros (and cons). Take a look at Dave’s blog for more information regarding the differences between SMTP and API.

Lastly, if you’re having problems setting up an SMTP relay, join our Community Slack channel, tweet us at @SparkPost, or shoot us an email!

-Vincent

Dev Survival Guide Blog Footer

Email Evolved Iguana Email API

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!

—Brent
@brentsleeper

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.)

Dev Survival 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

moxtra integration

Working with team members in an organized and efficient manner has never been more important. With so many applications at our finger tips, it can be hard to keep track of everything. Users are looking for easy ways to stay on top of team progress, without the burden of having to check multiple platforms.

This is why SparkPost and Moxtra are announcing an integration that delivers an embeddable, multi-layered cloud collaboration service. It lets people work the way they want to – on the go or at their desks, in real-time or anytime.

Moxtra focuses on delivering multi-layered collaboration for the enterprise through cross-platform, byte-sized APIs and SDKs.

SparkPost’s industry leading inbox placement and scalability makes it the perfect backend for Moxtra users who need to receive critical updates in real time. The great thing about SparkPost’s email delivery engine is being able to trust that emails will reach the inbox (not the spam folder) as actions take place. SparkPost’s RESTful APIs are perfectly designed for partners and developers of all sizes who want an easy way to integrate into the solution.

moxtra integration

Users can leverage this integration to send alerts in Moxtra. The alerts can notify team members of successes and failures, while receiving statistics right inside a Binder (collaborative workspace). If something actionable arises through a SparkPost notification, groups can instantly message each other, circulate important documents, or jump into a conference call to take action. This allows teams to go from problem to solution in a heartbeat.

SparkPost is built on the same proven technology that sends 25% of the world’s legitimate email. Combining this technology with Moxtra’s instant communication features, users are enabled to become masters of the “on-the-go” lifestyle.

moxtra integration

SparkPost and Moxtra are free to try for all. Click here to learn more!

Developer Week Recap

best use of api sparky award

Last week was a whirlwind of shaking hands, making connections, and building awesome things! From early Saturday morning until late Wednesday night, we talked to Developer Week attendees. The focus? What makes SparkPost different, how to use our awesome API, and why we’re the top choice for an email delivery platform. Here are a few of the highlights:

The Hackathon

hackathon developer week

The energy at the Galvanize co-working space was electric. With so many teams working on such amazing apps, we felt privileged that so many chose to work with us! We had teams building everything. From an app to manage food truck orders (for both vendors and customers), to a service that uses IBM’s Watson to analyze the tone of your emails before you hit send. Everyone could use a feature like that some days, am I right? Another team used our data and analytics UI to store webhooks and campaign data in order to easily re-send an email. The most innovative use of SparkPost however, was DwellWell.

DwellWell

Anyone who has spent a fair amount of time in San Francisco (or anyone who pays attention to the housing market), knows that one of the biggest problems here is a lack of affordable housing. There are several hoops to jump through to gain access to affordable housing, one of them being a mountain of paperwork. The DwellWell team, led by Marlon Frausto, built an app that enables applicants to complete their paperwork online, rather than making a trek downtown to deal with lines in person. The team did their research ahead of time, to gather all requirements for the affordable housing application process. Using SparkPost’s API, they built out a double-blind email system that allows people to inquire about a specific housing options. In addition to solving other problems, this gives applicants the anonymity they’re often wanting, but unable to have throughout the older process.

As they continue to build out the application and work with the city housing authority, we’ll be following their story and supporting their use of SparkPost.

dwell well hackathon

Dev Week Expo

Tuesday and Wednesday were the Developer Week Conference & Expo, inside the beautiful Pier 27 Cruise Ship Terminal. While we didn’t spend any time on a cruise ship, we did get to interact with several hundred attendees from all over the globe. We got great feedback on our API and had more interesting conversations about the various ways SparkPost can be used. Best of all, we got to see people get excited about building something awesome!

Build something awesome

If we didn’t get a chance to chat at Developer Week, say hi on Twitter! Tell us what you’re working on! You’ll also find us at BrickHack and FluentConf next month. Be sure to stop by and say hi!

domainsendingapiThe core purpose of SparkPost is to help developers easily send email from within their web and mobile applications. To help developers accomplish this goal, we have released the SparkPost Sending Domains API to help developers programmatically manage their SparkPost Sending Domains.

SparkPost Sending Domains API

Sending Domains are a way to map and authorize SparkPost to send email on behalf of your domain (example: myawesomedomain.com). This is accomplished by updating your domain’s DNS configuration to add specific SparkPost TXT records. These records provide proof to ISPs (Gmail, Yahoo, Hotmail, etc…) that you have authorized SparkPost to send email to your subscribers on your behalf. You can read more about the SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) TXT records in DNS here SPF and DKIM.

Until now, SparkPost developers needed to configure new sending domains through the SparkPost User Interface. As of today, we are pleased to announce that we have added the Sending Domain APIs to SparkPost and updated our API documentation to reflect this new addition.

The new Sending Domains API gives SparkPost developers the ability to easily create, retrieve (individual and collections), update and verify sending domains programmatically. Read the complete Sending Domain API Documentation. This will allow developers to much more easily configure and maintain their sending domains — let us know what you think!