2017 Annual Winter Hackathon

Another year is coming to an end. Per our tradition at SparkPost, we close it out with our holiday parties from coast to coast, and of course, our annual winter hackathon. This was my fourth hackathon with SparkPost, and it met the high standards set by the first three. I’m a big believer in our bi-annual hackathons. They give our amazing engineers a chance to tackle an issue or prototype a new feature or tool that they genuinely believe is important. The “Best in Show” winner gets to push their project to production. We’ve had some great features and fixes come out of it, including our A/B testing API, our Zapier integration, and HEML (by yours truly 😉). They are also a great chance to relax and get to know and work with people on different teams.

My favorite addition to the hackathon this year was the Game Truck. I’m not much of a gamer, but I really enjoyed losing dozens of times at games that I’d never heard of. To be honest, though, I was more happy to see that I hadn’t lost my edge in ping pong.

Animated GIF - Find & Share on GIPHY


Along with pong, at SparkPost we love all things AWS. This year we added a new prize: Echo Dots for the most innovative use of AWS technology. Jason Sorensen and Jacob Kleidman won this, converting one of the more burst-prone areas of our API to be completely serverless using Lambda, Step Functions, Kinesis, Cloud9, and SageMaker.

We had a fantastic lineup of projects this year focused on our five categories of Product, Tools, Partner Integrations, Fun with Data, and We Deliver. In the end, there could only be one. The winning team was (drum roll please) Threshold, with their impressive notification service for proactively notifying our customers about deliverability statistics. This tackles one of our most significant challenges, helping our customers be good senders and stay within best practices. The notifications will help them know if they are coloring outside the lines and help them hit the inbox.

From left to right: Chris, Nachiket, Jess, Travis, Amie

I can’t wait to see this implemented and, as always, there are a ton of new ideas floating around our offices for the next hackathon! Have an idea for our product? Feel free to tweet us! If you think this sounds fun, we’re always looking for new people to join our team!

Happy New Year Everyone 👋



Today, I thought I would point out a few of my favorite tricks when creating templates. Let’s call them email template hacks. I’ve briefly mentioned some of these in previous blogs, so today I’ll expand on those ideas and add in some use cases and examples.

1. Leveraging Substitution Fields in CSS

The first trick is to use substitution fields for your CSS values. Colors, fonts, height, pretty much anything can be substituted. Many email clients leverage header styles while others don’t. However you choose to tackle formatting your emails across various clients, you can leverage substitutions both inline, in the header block or both.

There are a few different approaches available if you want to inject CSS in the header block in order to maintain standards through all of your templates. The first method is to simply replace CSS values with substitution data. For example, if modifying the text color for an html <a> tag within the <style> block I would modify the color field to reference a substitution field. Here’s an example:

Then, in the transformations JSON call, I would have the corresponding substitution field:

This is the easiest way to modify the look and feel without having to rummage through hundreds of template and make changes. This also assumes that you are holding those values somewhere on your server and can retrieve them fairly easily for the transmission JSON creation.

Building this example up, you may use a dynamic_html and/or dynamic_text blocks. This allows you to make wholesale changes by bringing in large CSS blocks that you may be storing in a repository of standards. Change the blocks in that repository, and you change all of the templates that get the dynamic html/text referenced.

Please keep in mind that dynamic_html/text blocks are held within the global substitution_data blocks, now the recipient substitution_data blocks. A CSS block within the Transmissions dynamic_html structure may look something like this:

This code block is no different than if you had it placed in the HTML template itself. Now it’s just easier to update when referenced into the template via the transmission which pulls from a central repository. The template itself will use this code block with the following entry in the template somewhere in the html <header> block:

If you want to go all out, dynamic rendering even allows for recursive substitution fields. This means that the dynamic code block can have substitution fields as well. A good use case for this is when you OEM or White label your product. In the following example, the CSS block is similar to the one above, but there are substitution fields for the CSS values. Those substitution fields are then placed in the global substitution block of the transmission. For example:

But wait, what if I want to use inline CSS, you ask? Well, just change those big blocks of CSS settings and make them substitution fields.

2. Not sending the email at all if certain data does not exist

As emails become more personalized, they start to look and feel like transactional emails. This is a great trend, but it opens up a greater possibility for unfinished emails. Let’s say a job board sends lists of job opportunities to all active members each morning. Hopefully there are checks and balances that stop the application from requesting for an email to go out if there are no matches for that user, but as a template designer, I don’t want to rely on that. So a little trick that I use is to check for a specific substitution field or array that must be present; if it doesn’t exist, I call a non-existent function with the following line somewhere in the template (I tend to put this on the bottom). This will automatically kill that email from being generated so the bad email doesn’t make it out the door. In the example below, I’m checking for the ProductList array, and if it doesn’t exist, I call the function ‘crash’ with the parameter ‘onpurpose’.

3. Validating data before creating the table for arrays

SparkPost has a very powerful feature that allows a template to loop through an array in order to display a set of information, like jobs, real estate listings or products. In fact, SparkPost even supports having loops within loops within loops. Often, multiple tables, rows and columns get created order to display this information in the fashion the content creator wishes. But what if there is no data to show in one of those loops, but you still want the email to go out, just without the empty rows or tables? In many of my retail templates, I display a list of products that have ‘x’ number of features for each product. If there are no features, I still want the product to be displayed but I may not need to create some of the corresponding html code for the empty features list. In order to keep the email looking good, I check both the existence and the value of my arrays before building unnecessary tables, rows or columns that would house this information. This trick is solved with a simple two part if statement:

4. Using substitution fields in the subject line

So you built your template and placed it onto the SparkPost server. Don’t forget to create a dynamic subject line. One of the easiest way’s to get your email clipped by Gmail or buried into a huge thread is to use the same subject line over and over. So go ahead and use substitution fields for your subject. I often put the person’s name, along with a subject field. My Subject field in the SparkPost UI is set to something like:

5. Use dynamic_html for headers and footers

So, continuing on the theme of standards, I like to send my headers and footers to each template via the Transmission API in the form of a dynamic_html entry. This allows me to keep a library of headers and footers that can be easily modified without having to change every template. Because SparkPost doesn’t have the ability to store those headers and footers on the server then insert them into the targeted template, it’s a good practice to have those standard headers and footers in another content management system that marketing can change without developments help. When the transmission json is getting built, the appropriate headers and footers are placed into the dynamic_html section which is then pulled into the template before sending.

Upcoming Email Template Hacks

So those are some of my favorite template tricks. In my next blog, I’m going to tackle the trick of validating that the transmission payload has all of the data the template is expecting to receive. The blog will be accompanied by a full PHP code sample for this validation step.

Happy Sending

Jeff Goldstein
Senior Messaging Engineer

Any email template hacks we missed? Tweet us or come find us in our community Slack

10 Steps Great Deliverability Blog Footer

2016 hackathon review

2016 Hackathon Review

This year we challenged you to “Build Something Awesome” with SparkPost. To motivate you further, we sponsored 5 different Hackathons across the USA with cash and prizes. We also sent along our own engineers in order to mentor those who accepted our challenge. As a result, the response was incredible and we’d like to recognize the winning teams.

Developer Week

We started the year in February at the Developer Week Hackathon in San Francisco. We selected three teams that demonstrated the best use of our Inbound Email, Data & Analytics, and the SparkPost Heroku Add-on.

Best Use of Data & Analytics

Kaushik Ashodiya and his son created SparkPost ONTAP, combining our data with Net Cloud ONTAP to store webhook and campaign data. It allowed users to view or edit historical campaigns, as well as replicate the storage for disaster recovery and availability purposes.

Best Use of SparkPost Heroku Add-on

The team comprised of George Portillo, Stephen Fuller, Victor Sanchez, and Sal Casillas created Grab & Go, an application that leveraged the SparkPost Heroku Add-on to help alleviate the long lines found at the local food trucks. Their solution uses our transactional email to alert customers when their food is ready for pickup after placing an online order.

Best Use of Inbound Email

Marlon Frausto, Anna Wu, Ravender Virk, and Jigesh Parekh set out to tackle San Francisco’s affordable housing dilemma and created DwellWell. They used our Inbound Email to set up a double blind communication channel, allowing people to request information about a particular housing option with some anonymity. The DwellWell team has since continued their partnership with SparkPost to create PublicBNB.


In early March, we headed to Rochester Institute of Technology in New York for BrickHack. After 24 hours of hacking, we selected UBinE by Stephen James as the Best Use of the SparkPost API. This application uses transactional email to assist in planning, tracking, and notifying students of campus events.


In April, we headed to Bitcamp at the University of Maryland. Because of our close proximity, we got to send multiple engineers of our own to mentor at this 36 hour hackathon. Henry Saniuk, Sneha Vaswani, and Stuart Olivera won our “Build Something Awesome using SparkPost” challenge with their PiggyPennies application. This application made use of our inbound and transactional email and the CapitalOne API to while helping friends save money together.


After a long summer break, we headed to the University of California San Diego’s SDHacks, a 36 hour hackathon. At this event, Kevin Burns and Jack Zeiders had some fun with SparkPost and created an email based gaming service called QuibbleMail. Using only your email, you can challenge a friend to a game of Chess or Tic-Tac-Toe. Their use of SparkPost inbound and transactional email allows you to play without leaving your email client.

MLH Prime Southwest Regional

Finally, we wrapped up 2016 in Austin, where Major League Hacking pulled together the region’s best hackers for 24 hours. Bailey Breaux, Ali de Jong, Yuriy Minin, and Patrick Edelen blew us away with Mochi, their Jibo robot integration for patient care. The team used SparkPost’s inbound and transactional email to empower Mochi to contact a patient’s family via email and read aloud any replies.

At each event, the response to our challenges was amazing. So many of you Built Something Awesome and we thank you. As a result, we’ll be back out there in 2017 and we’ll be sure to keep you updated. Our first stop will be a return to Rochester in February for BrickHack 3. Because we take your feedback into account, we’d love to hear what events you’d like us to attend. You can chat with us on our community slack or send us a tweet @SparkPostDev.

— Aydrian

So, what’d you think of our 2016 hackathon review? What were your favorite hackathons from 2016? Any hackathons on the agenda for 2017 yet? Leave us a comment below.

Email Templates

Why Shifting from Internal Template Generators to Newer Platforms Makes Sense

Everyone has an opinion on how to build the best ’email templates’ that capture a customer’s attention and leads them to a call-to-action. Some leverage great graphics. Others use captions like, “The 10 Best Mistakes That Cost You Millions of Dollars That You Will Do Again!”

What’s often neglected is ‘how’ to build these email templates in a flexible manner that supports the dynamic needs that drive today’s complex business. At SparkPost, we have found that most companies moving from either an on-premises MTA or a self-service cloud ESP were forced to build their own template generators. Some are fairly sophisticated and flexible with a UI. Most, however, are complex pieces of code that build the email through a series of conditionals and saved text.

Over time, these applications have become fragile systems so changes or upgrades are rare, if any. Even simple changes to text within an invoice email can take weeks given the backlog of work development already has. Plus, they need to test it to make sure they’re not introducing further bugs.

With this in mind, I’m writing this blog, and eventually a series of blogs, to help our SparkPost customers see a vision of how they can move from these older systems and leverage the SparkPost templating system such as:

  1. Why making the shift from internal email generation systems to newer platforms makes sense
  2. The simple stuff, moving from SMTP and fully built emails compiled by development
  3. White labeling email templates; Using substitutions to modify look and feel of the HTML output for branding and white labeling
  4. Shared or Global data versus Recipient data
  5. Arrays and how to leverage them
  6. Dynamic output with multiple rows and columns of data
  7. Multi-language support

Many customers write their own templating system out of necessity. And since most are code-rich and depend on development to make the simplest of changes, Marketing gets hamstrung in their ability to keep up with the demands of a rapidly changing world. Because of this demand for change, when possible, it’s better to separate Marketing Design from Development; this is the key factor for moving to templating for many customers. This doesn’t mean that development won’t help build or customize some of the email templates. It just means that much of the work they were doing is minimized. In a perfect world, development worries about obtaining the right data that goes into the message. And marketing worries about the aesthetics and wording of the message.
In the long run, the speed of change that takes place by separating the creative from development is well worth the change.

Now that development doesn’t need to worry about the creative, they can simply focus on three things:

  1. What data to send each customer,
  2. What events trigger sending the content, and of course,
  3. Any segmentation to target the right users during larger blasts such as newsletters.

Another benefit of separating the creative from development is that pulling the data for each user becomes simpler. The need for conditional after conditional to get the proper data for a given template can be simplified to gather all the data for a user, then letting the template decide which data to use. If the template doesn’t use the data, we only lose the cost of transmitting it from the back end server to the SparkPost platform. However, don’t take this approach to the extreme by sending obnoxious amounts of unused data. Typically, there’s a bulk of personalized information that one can gather and send as a standard bit of personalization data for a template to use. Now, Marketing and Development can synchronize on what data will be available. Then, Marketing can ensure it’s used properly and presents itself in a manner fitting to their banding and messaging.

Now that we have a business case of why to shift from internally built email generation systems to newer platforms that separate out development from the creative, we’re ready for our next blog post. In the next one, I’ll discuss gathering the data necessary for substitution and moving away from fully built out emails sent via SMTP.

Happy Sending,

Jeff Goldstein
Sr. Messaging Engineer, SparkPost
Some Sample Email Templates

10 Steps Great Deliverability Blog Footer

Howdy there! You and I have talked before about how we build Slack bots at SparkPost, but I didn’t say much about how we use them. We use bots at SparkPost to do all sorts of things. We’ve learned a lot and I thought now would be a good time to share some of that with you. I love bots, you love bots, so let’s turn the lights down, light a few candles and have a nice glass of your favorite beverage over some bot talk.

How we use slack bots to stay productive people connected via slack

How We’re Using Slack Bots to Maximize Productivity

Like I said, we use Slack bots for a lot of things. We run our standups with bots, we use them to get links to our docs, to post sample data from our endpoints, and to encourage each other. We do internal reporting and monitoring from bots. We track the status of our deploys along with any new PRs and issues on our Github repos all from Slack.

Why do we use bots for all these things? I mean, there are other tools that do almost each one of the things we use bots for. Well, that’s the thing: there’s at least one tool for each of those things. Our Slack bots consolidate everything into one place and one interface.

There are some advantages to using Slack as that central platform for us at SparkPost. First, since we’re a distributed team, Slack has become lingua franca – it’s our primary communication tool – so everyone is comfortable with it. Slack access doesn’t require any special VPN connections (though you should set up two-factor auth for safety). It’s accessible on mobile devices so we can make API calls from just about anywhere. We make our Slack bots easy to use for non-technical people so they don’t have to use developer tools like cURL or Postman.

Basically, since we’re already in Slack on a regular basis, it’s easier and faster to simply perform as many of our everyday tasks from there as possible. Not only does it mean fewer steps to complete something, but we also don’t have to leave the interface where we’re already spending a lot of time. Just repeat this over and over with me:


Botify All the Things!

So how do you choose what to add to your bot? Be on the lookout for things that are inconvenient or painful. Start with the things you do a lot. For example, in our community Slack team we found we spent a lot of time tracking down links to our docs: we’d open a browser, go to the docs page, search for the right resource, copy the link, go back to Slack… It was just awkward. And in that time the conversation would often have moved on. Now we have a single command that will give us a link to the resource our users need when they need it.

Do you have something that only you can do because you’re the only one technical enough? Bam! Slack bot! Or do you want to empower your team to do things on their own? Botify it! Want to let new users know what’s up when they join your Slack team? Bot time! You get the picture. It’s open-ended, the only limits are your creativity and a few pesky natural laws.

How to Succeed at Bots Without Really Trying

Ok, you have this awesome idea for this bot that is going to save you time and frustration and probably the world. You set up a repo and a sweet continuous deployment pipeline for easy deployments. You’ve got 100% test coverage, the build is green. But nobody is using it. Nobody? Seriously? Yep, nobody.

Remember, bots are an interface, just like a web page. And just like any web site they can be hard to use or unintuitive or just plain off-putting. Bots have the extra challenge of being a pure text interface to your code and code is rigid and brittle. But human language is fluid and nuanced and weird. So when you build your bot be creative, funny, and offbeat. Find that unique voice inside of you and channel it into your bot. That helps offset your bot’s rigidity (and even make it endearing!).

Making your bot enjoyable goes a long way to getting users to engage with them. We’ve also found a lot of success by including help text for every command. The skellington library we use for our bots makes help text a first-class citizen and makes it easy to add help messages. The easier and more fun you make the bot to use, the more people will use it!

If you use Slack or some other chat program, bots are a great way to empower your team and make rote tasks easier. Make your bots useful, interesting, and entertaining (in that order) and before you know it your bots will take over the world! Ok, not the world but at least the hearts of your users.

– Cole Furfaro-Strode

We’d love to hear how you’re using bots! Either post a comment below, or come find us in our Community Slack channel.

we love developers

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 “[email protected]”, 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 or check out these resources in our SparkPost Academy!


Dev Survival Guide Blog Footer

Community Spotlight Q&A SparkPost Tutorials

One of our greatest joys here at SparkPost is creating tools and watching our community members run with them. From improving on what we’ve built, to creating SparkPost tutorials for other community members, to writing entire client libraries, it’s clear that we’ve got a talented group of people using our product. As our social media manager, it’s so incredible to see these tools and libraries evolve and ignite some great conversations online.

We’re continuing our community spotlight series today by sitting down with Chris Pitt, a community member that we first met at Fluent, who’s contributed to our community in a number of different ways. Aside from his What is SparkPost blog, he’s also featured SparkPost tutorials in a daily coding series on his YouTube channel – you can view “Sending Email with SparkPost” parts one, two and three there. Chris is an overall delight and a very talented developer. Enjoy!

How long have you been a developer, and what got you started in the tech world?

When I was younger I wanted to be an electrical engineer. My parents got a computer, and I started spending more and more time on it, mostly playing rogue-like games.

Later, they bought me a computer. By the time I finished school, I really wanted to do something with computer hardware. A family friend had a business selling, amongst other things, computer networking hardware. He had a website (which was a big thing at the time), so he convinced the agency managing it to let me “hang around” and watch what they were doing. I guess I just never left…

What do you like about being a developer?

I love learning new things. Programming gives me an out for that, because there are more new things happening all the time than there is time to learn all the new things.

What’s a myth about software development you wish you could dispel?

That it is too complex for some to learn. That belief turns many capable people away and becomes a goal-post for others. They chase complexity as a demonstration of how well they know the limitations of a language or the nuances it provides.

The best programmers I know thirst for simplicity. They set fire to their old code and habits. They realize how vital it is that others can understand what they’ve written.

Do you think having a developer’s mindset causes you to see solutions to non-technical problems in any particular way?

I think that depends on what you enjoy about programming. For some people, approaching things analytically is just natural. They are the kinds of people that have to solve a problem, when sometimes all you want is for them to hear you. On the other hand, having someone around who won’t quit until things are “just right” can be a source of sudden and unexpected progress.

For some people, the expression of creativity is the most compelling thing about programming. For those people, programming is just a learned expression of the tools they already have and use.

Any interesting examples come to mind?

I work with this really talented woman, who uses JavaScript to augment her sketches and paintings. She enjoys learning how code can extend the talent she already expresses, and would continue to make amazing artwork even if she never opened another code editor.

I’m one of those people who wants to analyze everything. It takes a lot of effort to just listen, because I just want to fix all the things.

What does community mean to you as a developer?

It’s a matter of life and death to me. I often go back to an article called “The Ghost Who Codes” because it so accurately describes what I was like before I actively sought community with other developers. In it, Troy Hunt describes someone who takes and takes, never trying to give anything back. A person without a paper-trail. A ghost.

I can tell you exactly when I started to play an active part in the PHP community because it made such a difference to my enjoyment of programming, and my career growth as a result. It was when I joined my first user group, about half way through 2013.

Since then I’ve presented at ten conferences, published four books, and traveled the world. These are things I would not otherwise have had the support, encouragement, or ability to do without the community.

How do you like to communicate and socialize with other devs?

Meet-up groups and conferences are the best places to meet other programmers in person. For everything else I use Twitter. I would be in such trouble if it went down for good…

What are some of the issues (pro or con) you’ve run into when contributing to open source work?

People can be jerks sometimes. The weight of maintaining a successful open source project forces people to either be unresponsive or terse. Sometimes that terseness becomes rude. At that point it’s hard to continue being excited about contributing to that project…

What’s your favorite language and why?

I’m really liking JavaScript at the moment. Some of the newer syntax make it easier than ever to write simple, functional code. I enjoy PHP mostly because of the community working with it.

What are you working on right now?

I’m spending a lot of my time writing these days. If you set aside my day job, I probably spend about 75% of my career time on writing. The rest I spend working on various open source tooling things, like undemanding testing frameworks and async PHP standards.

What’s in your dev toolkit?

I develop on a Mac, using PHPStorm for any serious PHP development, and Atom for everything else. PHP/MySQL is installed locally (no virtualization), as I find my Macbook too underpowered to run iTunes, Chrome, PHPStorm and VirtualBox all at the same time. Now that Docker (Beta) works without VirtualBox, maybe I’ll switch to using that. For hosting, I use Digital Ocean and Laravel Forge, for continuous integration, I use Travis and Scrutinizer.

How do you use email in your apps and projects?

Email is a huge part of account management. You can’t really build any substantial application, these days, without sending a few different types of transactional email. For a long time, the task of sending those emails fell to Mandril. Then they ended their free account support and in a panic I discovered SparkPost.

How did you find SparkPost?

I heard about SparkPost at a conference. They were one of the sponsors and were honest about their services and competitors. The kind of honest that made me want to check them out…

What led you to contribute and create the SparkPost tutorials live coding videos?

Streaming is a way for me to commit to learning something new every day. After the conference, I decided to write some code to talk to the API – a kind of alternative to the PHP client their already have. It was quite fun actually. You can check it out on YouTube, if you’re keen to see what I got up to.

What’s something you love/hate about email?

Setting up and maintaining a trusted email server is a pain. I love being able to use services like Gmail (for personal email) and SparkPost (for transactional email) and not have to worry about my mails bouncing. Ain’t nobody got time fo’ that!

What are you passionate about outside of work?

I have the best family. Don’t even try to argue! I enjoy hanging out with them and making them laugh.



Thank you, Chris, for taking the time to chat with us, and all of your contributions to the SparkPost community!

To keep up with Chris, be sure to follow him on Twitter or subscribe to his blog.

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.


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 😉


Biz Eval Guide Blog Footer

This last weekend we sponsored Bitcamp, held at the University of Maryland, and in my opinion, it was one of the best hackathons we’ve ever attended!  Now would be the right time to disclose my bias: I was a Bitcamp organizer in college. So having my first experience on the other side of the sponsor booth be at my favorite hackathon, was truly special.

It was also a significant event for our Developer Advocacy team. SparkPost has sponsored small to midsized hackathons in the past, but this was our first delve into the larger student-run events, and we came prepared!

We started Friday night off by giving away tons of swag, including the limited-edition SparkPost Bitcamp stickers.

bitcamp sticker piggy pennies
SparkPost Bitcamp Stickers

These were such a hit with the hackers that we’re in the process of creating limited-edition stickers for other events! Come see us at one of our next events to get yourself one.

On Saturday, we brought in a slushy machine and served Monster Energy slushies (there was a fruit punch flavor for those who had actually slept).

slushie cups piggy pennies
Limited Edition Slushy Cups

Handing out swag and raffling off prizes is always a fun time, but what made the event really worthwhile was being able to help students with their projects. Throughout the weekend, we had six SparkPost engineers answering questions and mentoring hackers.  Nothing took me back to hackathon participant times like debugging a node.js app at 3 AM on Friday night! We even got a shout-out from one of the hackers on Twitter.

twitter piggy pennies

Whether hackers built their projects with SparkPost in mind or quickly incorporated, we got a lot of great submissions for our challenge. The deliberation was tough, but Piggy Pennies walked away as the winners of the SparkPost Challenge, with $500 in Visa gift cards. Piggy Pennies allows you to automatically round up the change of your purchases in order to save money towards a common goal with friends. The team leveraged the Capital One API (available only at hackathons) to process financial transactions, and used SparkPost Transmissions and Templates to deliver detailed updates and reports on the group’s goals. The team also implemented ways to trigger money transfers by replying to the reports using our Inbound Relay Webhooks.

bitcamp winners piggy pennies
Piggy Pennies – The Winners!

The rest of the challenge submissions were amazing too — 6 of them won major prizes from other sponsors as well. They were so cool we had to pick two honorable mentions to send to extra swag to. Contap took a new approach to the “tap phones to exchange info” concept, by automatically starting an email intro and implementing Amazon Echo Alexa reminders to contact the person. The second honorable mention was part of a surprising amount of hardware heavy submissions. Fireberry Pi used sensors and a RaspberryPi to send a warning text message including a picture of the room when gas levels were too high. This team was particularly crafty, figuring out how to use carrier email to sms gateways to send a text messages using SparkPost.

Bitcamp’s theme this year was “Explore new grounds,” and I can confidently say the SparkPost team did just that. It was a great place to meet up with such a large number of developers at varying stages of experience and skill levels. We got really valuable feedback on our product and even met a participant who had recently published a SparkPost Cake-PHP Library!. Thank you to Bitcamp for putting together such a creative atmosphere. Thank you to all the hackers, we hope to see you again soon.

Make sure to reach out to our team on Twitter or in our community Slack channel if you want to connect!