Zapier and SparkPost

Today’s blog is by guest author Chris Dunne, who writes for the GetJirified blog. The original post can be found here.

Creating Magic using webhooks with Zapier and SparkPost for email

JIRA Service Desk is a great product. It provides all the essential features to set up a fully functional business and customer friendly service desk. It is, like the rest of JIRA, quite flexible.
But there is one area that I believe is seriously lacking in terms of flexibility. Email Handling!
Whilst many users will prefer to login to the portal and raise requests, others will prefer to email. The majority will prefer to receive change notifications for requests by email too.
The ‘Default’ Email Notifications feature is baked into JIRA Service Desk. This will send customers email notifications using Atlassian’s own built-in HTML email template.

Zapier and SparkPost notification message

But many JIRA Service Desk customers want to send these emails with their own branding, own look and feel, and customized data items in the body of the email.

The lack of ability to customize this essential function has been outstanding for a long time. Check out JSD-218 – As an Admin I want to be able to customize the Service Desk notifications’ subject, content and format

Read through the 330+ comments and you can see there is a lot of frustration in the community with Atlassian’s lack of progress on this issue. Only recently Atlassian announced a slow rollout of features related to Email customization in a beta program for JIRA Cloud customers.

The comments do provide some workarounds using ScriptRunner and velocity template modifications but I wanted to see if I could come up with an alternative that didn’t involve add-ons.

Without further ado, let’s define the requirements. We would like to be able to do the following:

  • Send emails in response to events on issues in JSD.
  • We want to be able to completely customize the look and feel of those emails.
  • We want to be able to insert data from the issue into those emails.
  • The emails should come from an email domain that the customer recognizes and won’t be blocked or treated as spam.
  • Customers should be able to reply to these emails.

In this article I will show you how you can do all of this in JIRA Service Desk (for both cloud and server versions). We will use a combination of JIRA’s webhooks, Zapier, and SparkPost.

JIRA Email Notifications

So what are these email notifications that JSD / JIRA sends? They are emails, triggered by JIRA issue events that are sent to a defined set of recipients. The content of the email is defined in a template.

When we are dealing with JIRA Service Desk there are actually two flavours of email notifications.

  • JSD Customer Notifications. These are the notifications that are baked into the JIRA Service Desk project. There is very little we can do to change the behaviour of these notifications, or customize the content. We cannot change the layout or content without cracking open the source code, and on Cloud this is not even an option.
  • JIRA User Notifications. This is the traditional means of sending email notifications. Using notification schemes, we have the ability to define who receives the notifications for each type of event. But these email notifications are only sent to licensed JIRA users and not to JIRA Service Desk customers (free, and unlicensed). For the server instance we can also modify the Velocity templates used to control the layout and appearance of the emails.

Here are some examples of the out-of-the-box notifications; one is a standard JIRA Service Desk notification a customer would receive and the other is the type of notification received by licensed JIRA users.

Zapier and SparkPost notification message

Zapier and SparkPost notification message

The challenge for many Atlassian customers, and the challenge we set out to tackle in this article, is to provide a mechanism to change the content and branding of the emails, preferably without additional plugins.

An Alternative Approach

We want to send customized emails in response to events in our primary system. When you think about it this sounds a lot like the function of transactional email systems like Mandrill and SparkPost.

These are normally used in e-commerce systems to send receipts and other automated replies. They provide users with the ability to trigger emails and define templates for the content of those emails.

So I thought – could we disable JIRA’s native notifications and instead use one of these transactional email systems.

To do that we need a means of sending a message to our transactional email system when an event of interest occurs in JIRA. JIRA has webhooks which can do exactly that. But we need something that would catch the webhook, parse the content, and trigger the sending of the email.

Zapier has the capability to do this and is quite easy to set up.

Finally, we need to have something to actually send the email. There’s a bunch of candidates, but the new kid on the block is SparkPost and I’ve decided for the purposes of this post to give it a try.

So the next step is to set up our accounts with Zapier and SparkPost.

Zap it

Firstly lets set up the Zapier account we need and create the webhook we are going to use.

  1. Create your account on the Zapier site here, and sign up for a free plan.
  2. Click Make a Zap and then select Choose App under trigger. Type Webhook and select the result.
  3. Select the Catch Hook option and then click the Save + Continue button.
  4. On the next screen select Continue. A custom webhook URL is generated. This is the webhook that JIRA will use to trigger the Zap. Click the Copy to Clipboard button.
  5. Click OK, I did this button and keep this window open. Zapier is waiting to intercept this webhook. So we need to open another window and set up the webhook in JIRA.
  6. Go to JIRA->Admin->System->Webhooks and configure the webhook.
  7. Give the Webhook a name.
  8. Paste the URL copied to the clipboard in step 4 into the URL field.
  9. Select the events that will trigger this webhook. We will select the Issue Created and the Issue Updated event.
  10. Click the Save button.
  11. Now create an issue in any project and switch back to your Zapier browser window. Zapier should detect the webhook. You can click the view your hook link to see the actual data sent.

Note: In part 2 of this article we will further customize this to fire events from our workflow, restrict the issues we are interested in using JQL, and create webhooks for other events.

Here’s a screencast showing you what to do.

So we have JIRA talking to Zapier and sending the details of events as JSON.

But this is only half the story. We can’t complete the full Zapier definition yet as we need to also configure SparkPost.

Spark it

Now we are going to set up our email system using SparkPost. We just want to test a very basic scenario and ensure that we can send an email with some data from our JIRA issue created/updated event.

So first we need an account and then an email template.

Setting up a SparkPost Account and Linking it to Zapier

  1. First things first, set up a SparkPost account here. When you first set up an account, SparkPost will ask you about your sending domain. I advise skipping this for now. Click the Skip For Now button.
  2. Click the Get A Key button under ‘Send with REST’. Copy the Key to notepad.
  3. Switch back to Zapier. The next step is to set up the Action which will be called when the Zap is triggered by the webhook.
  4. In Choose App, type SparkPost and select it. The next step is to Choose the Action. There is only one – Send Email.
  5. Click the Connect a New Account button. Paste the key you just copied and click Yes, Continue.
  6. Click the Test button next to the new account. If this is successful, click Save + Continue.

Here’s another short screencast to demonstrate these steps, although in this case I already had a SparkPost account.

So we’ve connected Zapier and SparkPost. Next we need to trigger an email in SparkPost. We need a template for the email.

Setting up the SparkPost Email Template

  1. On the next screen we can select the Template for the email that SparkPost will send. Right now we don’t have any template, but there is a draft template called “My First Email” set up for you in SparkPost.
  2. Switch to the SparkPost browser window.
  3. Click Templates. Then click My First Email. This will bring you into the editor. We are just going to use the default template as this is really a proof of concept.
  4. Our Zap is going to take some data from the webhook body and construct a subject line that contains the Issue Key and Summary. In the Subject field in the template editor enter the text “{{mysubject}}” (without the quotes).
  5. Click the button to Save & Publish.

Double-check your work with this screencast.

Complete the Zap

  1. Switch back to Zapier to complete the configuration.
  2. Select My First Email in the Template ID field.
  3. In the Inline Recipients field choose Issue Fields Reporter EmailAddress.
  4. In Substitution Data we provide key value pairs. The first field box is the key and here we can enter the key name mysubject. The second box is the value and here we can select Issue Key from the dropdown. After Issue Key, type a ” – ” (space, hyphen space) and then select Issue Fields Summary from the dropdown. This builds up a string of text for the subject line which will be injected into our email template.
  5. Click Continue and a test email should be sent to you.

This screencast shows the setting up of the key value pairs in Zapier.

Now let’s see if it was all worth it. Create an Issue in JIRA using your own account. You should receive a notification from [email protected] and the email subject line should contain your new issue key and summary. Then update any field, such as the description field. You should very quickly receive another email from SparkPost.

Hopefully it worked. If not, get in touch with me on the comments and I’ll try to help you diagnose it.

Zapier and SparkPost Together

OK so there are quite a few steps involved but they are reasonably simple and give you a good sense of the power of Webhooks and Zapier. Let’s review where we are at and what we can do next.

At the beginning of this post we set a number of requirements.

  • Send emails in response to events on issues in JSD. We are using webhooks, triggered by JIRA events, to trigger emails using Zapier and SparkPost.
  • We want to be able to completely customize the look and feel of those emails. Although we didn’t show it here we have full access to the email template in SparkPost and we can completely customize the emails. Check out the SparkPost docs for more information.
  • We want to be able to insert data from the issue into those emails. We can inject substitution data (issue data from webhook body JSON content) into the templates. In this example we only injected data into the Subject but we can also do this in the body of the email. You can read up on the substitution data and its capabilities here.
  • The emails should come from an email domain that the customer recognises and won’t be blocked or treated as spam. We used the * domain as the sender domain for our proof-of-concept. You can set up your own sending domain and then verify it with SPF and DKIM to allow SparkPost send emails from your own domain. See docs here.
  • Customers should be able to reply to these emails. We have not yet addressed this requirement. But I believe it is possible and this worked in my initial tests. You would first need to set up sending from your company mail domain so that notifications arrive in recipients inboxes coming from [email protected] When customers reply, the replies will go to this address. If you have JIRA set up to poll this account then JIRA should be able to process those emails and add the replies to the original issue. Alternatively you could auto-forward the emails to whatever email address is configured in JIRA.

To be honest I have not had time to completely test all scenarios and this is merely a proof-of-concept. I hope it inspires others to try this out and if you feel like it please add comments below and share your results.

In the next post (assuming there is interest), I will look into how you can send the emails from your own domain, how to filter the events using JQL, and how we can customize the email templates. I’ll also look at triggering the emails from workflow transitions and by using the JIRA Automation Plugin.

We won’t be able to create an email notification system as flexible as Notification Schemes but I think we can solve the problem of customizing email content for JIRA Service Desk customers.

-Chris Dunne

Chris Dunne - Get Jirified Blog Author Zapier and SparkPost

 slack bots

We use Slack a lot at SparkPost. A lot. We use Slack so much we just made another public Slack team so we never have to be far from that beautiful brush-knock sound.

We love Slack because we are distributed (I work on a team that spans eight time zones) and being in touch so much helps us stay productive (usually). We also love Slack because it’s extensible. I’ve built a few bots here at SparkPost using the botkit library to help us run standups and to help out our developer advocacy team. I thought it would be fun to share our approach to building, testing, and deploying our Slack bots.

Humans First

At SparkPost our mantra is “API first”, which is really another way of saying “humans first.” We work very hard to build clean, well-designed APIs that are consistent over time. And we do that because we know as developers that’s what makes our lives easier. So even for our internal tools, our guiding design principle is “what will make this the best tool for this person to use?”

For bots I am usually asking: What makes this command easy to remember? Is the phrasing/syntax similar to other commands or tools the user is used to? Will the users like something straightforward (@bot award a point to @user), or will they prefer something a little quirky (@bot pointify @user)? Maybe both!? Then I sketch out what all the interactions will be. Only after I know how the bot will behave and how people will interact with it will I start writing code.

Then Computers

Humans are great, the best really. If you’re a human, you’re A+ in my book. But robots are also awesome, and they are especially good at the boring repetitive tasks we humans don’t like and tend to mess up. That’s why we automate things like testing and linting to make sure our code quality stays high and unbroken.

For our bots, I set up a TravisCI continuous integration server that runs linting checks and tests on every pull request and every code push. I also add automated checks ensuring code coverage doesn’t drop (otherwise it’s just too tempting to not write your tests 😉 ). Pull requests aren’t merged in unless they pass CI. And once a PR is merged to master, we run it through CI again to make sure there are no regressions introduced by the merge. If the CI passes, the code is automatically deployed to a staging environment.

By automating so many rote tasks, we can have a lot of confidence that our code works and that new features aren’t going to cause regressions in our existing ones. But if I learned anything from Wall-E, it’s that robots can’t do everything by themselves.

Then Humans Again

Automated tests and linting are great, but they won’t notice things like inefficient code paths (I’m looking at you nested for loops). And 100% test coverage is an awesome goal, but that’s only one metric for test quality. Tests can cover 100% of your code without meaningfully testing anything or they can miss important edge cases (like error handling at the end of a promise chain). That’s why every line of code (including tests) is reviewed by another person. Our reviews are conversations, not just throwing code over a wall. Having another perspective can be invaluable. A lot of time, as a programmer I’m focused on the microscopic world of lines of code. A reviewer has a chance to step back and look more holistically, catching something that I might miss. Once the code review is done, we start our user acceptance testing to get more feedback from a non-technical point of view.

It’s important to get feedback as early as possible, this prevents churn later down the road. For our bots I ship one command at a time, complete with tests and docs, and review the changes with a few key users. I want to make sure that everything works for our users. At that point it’s easy to iterate quickly because we have focused feedback.

We have private channels dedicated to user testing staging bots, but you could easily set up a separate Slack team for testing if you don’t someone to stumble on your not-ready-for-primetime bot.

Back to Bots: Automate Shipping

We host our bots on Heroku. We create two apps: one for staging and one for prod. Once a bot passes user acceptance testing in staging, we promote the app to prod using Heroku Pipelines. One of the nice features of pipelines is the same slug we tested in staging is the one that gets deployed to production; there’s no recompilation or re-installation of dependencies. Shipping the same artifact we test keeps our confidence in our bot high, which is good because people are not happy when Slack doesn’t work. If you want to anger someone on the internet, just take away their ability to post cat GIFs.

The Long Way is the Short Way

It’s funny, you would think that all this process outside of coding would slow us down. Taking time to sketch the user interface, writing tests, reviewing code, building automation workflows and talking with people. But we’ve found the opposite to be true. Including people early on, and taking time to build automated tools help us ship more features faster. One of my mentors used to tell me “the long way is the short way.” By investing time and effort up front, we deliver a high quality product that is exactly what our users want: a bot that will show them GIFs of guacamole whenever they want.


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.


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!

reporting with sparkpost using node.js

SparkPost is the world’s most powerful email platform. Our engineering team takes advantage of this fact by using SparkPost to power several pieces of functionality within SparkPost itself. One of the areas we use SparkPost is to power our internal reporting. In this post I’ll demonstrate how we use SparkPost to build an email report.

We’re going to build what we refer to as our sending domains report. This report goes to our deliverability team, which ensures we follow best practices to help our customers succeed. We’ll use Node.js, demonstrate some queries in Cassandra, which is where our customer data lives, and pull it all together with the templates and transmissions capabilities of SparkPost.

The content of the email will be a simple heading and table with a row for each record in the data we retrieve from Cassandra. Here we create a template that makes use of the SparkPost template substitution data:

We’ll create a new template with the ID sending-domains-report by going to the SparkPost Templates UI and pasting the HTML content into our template editor:


Let’s break down what we’re doing in the template:

First, we have a heading and an if statement. We use this statement to see if the domains variable is empty (we’ll show you where that comes from later). If it is, the template will just show a friendly message.

If the domains variable is not empty we create a table with a heading row:

And finally we loop through each item in the domains variable and render some data:

Now that we have our template, we need to create a Node.js script that queries our Cassandra database and uses node-sparkpost to send the email.

First we have to require some libraries:

Next we create the functions for retrieving data from our sending domains and accounts tables. Note that we created our own wrapper around cassandra-driver to promisify the batch/execute methods and add an executeByStream function that allowed us to stream back more than 5,000 results:

We have to do some processing on the data returned from the queries to merge them together:

This function is responsible for sending our message through SparkPost using the node-sparkpost library. We use the config library to set up our connection to Sparkpost, prepare the message meta and substitution data and deliver the message:

Finally we pull it all together into a promise chain and log out the results:

You can view the code in full as a Gist on Github. The end result an email report that looks like this:


Internal reporting is only a small sample of how we use SparkPost at SparkPost. In a future post we will dig into how we use SparkPost to power the various emails that are sent to users of SparkPost.


Dev Survival Guide Blog Footer

Happy 2016 from SparkPost

You saw by Irina’s post on Wednesday, as we embark on a new year we’re very excited about what we have planned for SparkPost in 2016!

Also don’t forget to check out what some of our developers have created with our code in our latest hackathon. Or hop on over to the Developers Hub to explore more.

To stay up to date on the latest email marketing trends and to find out what’s coming down the pike in our SparkPost, Momentum and Port25 products follow us on social media (below) or subscribe to the blog . As always, your opinion is important to us so if you have any requests, please let us know in the comments below or on Twitter @SparkPost or @SparkPostDev.

Happy 2016!
~ Tracy

Error Logging

Mistakes happen. It’s a fact of life. But, mistakes are often a precursor to growth…as long as you learn from them!

Early on after launching our service, the SparkPost support team occasionally received feedback from customers who tried to sign up for one of our paid tiers, explaining that the transaction failed. Not only did that stink for our customers, but it was a real pain point for us as well. We knew that sort of error couldn’t continue unchecked, so we decided to get to the bottom of this frustrating problem.

We integrate with a third party for payment processing, and the third-party system sometimes responds to a request with what’s essentially an unknown error. Super helpful! In most cases, we were able to surface a more helpful error to the user based on logic that parses the response. But up until a few months ago, we had zero visibility into the unknown errors. We had no way to help our customers, and no way to learn from the problem! After looking at a few more third-party solutions, we decided to leverage functionality our current stack already provided.

Some updates to our Angular-based UI and our Nginx web server was all it took. And while we were at it, we went ahead and used the approach to log uncaught exceptions, too. In the front-end portion of our application, we built a simple service for posting errors to Nginx. We just have to get the username from the session, along with the error response and data posted, and post it back to our logs. (Of course, for compliance reasons, we never deal with actual credit card information; our third-party service takes care of that.) No need to catch a rejected promise in the service either, because for our case, we don’t have a need for handling failed log attempts.

From the Nginx side, we’re able to customize our log format by leveraging the built in directives and variables available in the core module as well as the log and proxy modules. In our case, we’re using the access_log and log_format directives, and the $msec variable from the log module. Then $proxy_add_x_forwarded_for from the proxy module. We get $http_user_agent and $request_body from the core module. With that in place, we can easily see information about the request, in addition to the data being sent from the UI.

Finally, back to our front-end code and the case of uncaught exceptions. Angular comes with a global application exception handler $exceptionHandler that does exactly that. In our case, we use the $provide service’s $decorator method to add additional behavior. It’s called in the config phase callback, so that the decorator can intercept the service creation, and we use the $delegate method to retain the exception handlers base functionality.

As any JavaScript developer will know, we have a lot of new tools at our disposal today. But, by knowing your existing tools well, you can arrive at simple, clean solution that addresses your problem without having to pull in extra dependencies, and without the need to learn additional APIs.

Now, whenever our support team needs to assist customers with their subscriptions, we’re able to quickly access additional details, and as an added bonus, we have an easy way to gain insight into exceptions within our application to prevent future occurrences! Learning from this previously frustrating error turned out to be an opportunity for improving the customer experience—and for making the internals of our application better, as well.


You might have heard about SPF and DKIM, and you might even know that they’re email authentication standards. But a lot of the information out there about SPF and DKIM is a little hard to understand. That’s why I’m going to lay it out in an easy-to-understand way and give you some tips for setting them up for your own domains.

In the earliest days of what we would recognize as modern email, there was little in the way of sender verification. Pretty much all spam, scams, and viruses that spread through email did so using falsified sender information – as they still do today. So how can you be sure that the sender is who they say they are?

When you go to, you’re generally pretty confident that Google has control over what gets sent back to you. This is because the Domain Name System (DNS)—a distributed network of servers that act as a phonebook—connects the domain with a variety of records, including where to find the real

Email uses a later adaptation of this same system to verify senders. Specifically, we use what’s called a Sender Policy Framework (SPF) record. Much like your browser does when you type in, your email client will look up the DNS entries for any domain you receive email from and make sure that the domains listed there agree that the server sending the email is legitimate.

Think of it like this: if you wrote your own name and someone else’s return address on an envelope and sent it to me, SPF is a way for me to call each of you up and make sure it’s legitimate. But then how do I know it’s actually you that wrote the contents?

That’s where DKIM comes in. DKIM is a combination of DomainKeys, originally designed at Yahoo, and Cisco’s Identified Mail.

DKIM uses public key encryption which, to criminally oversimplify, is basically a giant math problem that takes forever to solve unless you have two very specific hints. One hint I make publicly available, the other I send along with the message. If you feed both of those hints into the problem-solving machine and it gives you the answer, then you know I wrote the contents.

Implementing each of these layers of validation is pretty straight-forward and SparkPost makes it extra simple. In fact, SparkPost handles the SPF part automatically, so all email from your account is already SPF-compliant.

That leaves just DKIM for you to configure. Here’s how: When you log into your account, under Account > Sending Domains you can find the DNS entry you need to add. In your host dashboard, you should see a section for DNS entries. If you just set up this host or domain, this should look pretty familiar.


Some hosts will mention SPF records here, but you’re looking for a generic TXT record.

There are two parts to a DKIM record: the host name and its value. You will want to paste the DKIM record value you copied from the SparkPost dashboard earlier. Submit the form, and you’re set.

By the way, not all registrars allow you to add DNS records to arbitrary host names, which is necessary for DKIM setup. Most of the time, they can do it for you, but you might need to go through a support request for it. For specific instructions for different registrars, you can check out the DKIM support guide.

P.S. If you want to check to see if your email is SPF and DKIM enabled, you can use our Validator tool.

Alex Mohr

Alex Mohr runs marketing and analytics for and works tirelessly to rid the world of bad coffee and bad emails.



10 Ways To Build Brand Trusty and Loyalty Through Transactional Email

SWUSPIn the days of yore, after an email was triggered, say by a user signing up for your site, a welcome email would be assembled from the code stored deep within your app and sent directly from your server via SMTP. This meant that if you wanted to use dynamic data, like that user’s name, you would have to navigate your database and pull it out. Similarly, if you wanted to make updates, you had to dig into the codebase.

We’ve come a long way since then, with advanced tools to maximize and optimize along the way. Tools like SparkPost specialize in deliverability – maximizing your ability to scale quickly and indefinitely. Services like Sendwithus give you the power to manage complex email workflows as you reach that scale.

The first step is super simple, you just need to get your tools ready.

What you’ll need:

Now, once you import your templates, all you need are some triggers.

[If you’re using a service like Segment or Zapier, you can jump ahead to our quickstart automation guide.]

A trigger comes in the form of an API call, which is basically just a list of variables and their associated values. In this case, those variables will be things like which template to send, who to send it to, and your API key which – as we saw earlier – will serve as your authentication.

You can see the whole thing come together in our live example.

From there on out it’s all tinkering: set up an A/B test, experiment with different triggers, build out drip campaigns, you name it.


Alex Mohr runs marketing and analytics for and works tirelessly to rid the world of bad coffee and bad emails.

If you build it, they will come” may be true for baseball fields, but it doesn’t hold true for APIs. Any company that’s serious about the success of its APIs must take the time to reach out to the developer community and help Ben Aydrian Steven
them succeed. That, in a nutshell, is the job that Benjamin Dean and I have been hired to do as SparkPost Developer Advocates.

People often ask me what I do as a Developer Advocate. My primary responsibility is to explain the awesomeness of the SparkPost API. I travel to conferences and hackathons to promote the API and educate developers about SparkPost. I share the Message Systems story, give demos, and present use cases. My goal is to explain that although SparkPost is a fairly new product, we have 15 years of experience and expertise behind SparkPost, and our APIs make it easy for developers to get ahold of all that awesomeness. In the case of hackathons, I have the pleasure of meeting lots of you, not to mention giving away cash and prizes to developers who demonstrate innovative uses of our API. Most recently we awarded a Parrot Bebop drone at AngelHack Brooklyn.

As a Developer Advocate, I’m also responsible for ensuring developers’ success with the SparkPost API. Sometimes that means working with the support team to identify common issues. If we see trouble tickets for a particular category and think something could be clearer, we’ll write a blog post or create a tutorial video to make the product even easier to use. We also network with developers and answer questions via email, Twitter, GitHub, StackOverflow, and Heroku (we recently entered beta as an email add-on in Heroku).

Aydrian Dev Adv2Ultimately, however, it’s about having face time with the community and building rapport with you as developers. Benjamin and I strive to build our knowledge beyond SparkPost and serve as true thought leaders so that we can deliver more value to the developer community as a whole. I look forward to meeting you face to face one of these days. Follow me at @aydrianh to find out about where we’ll be next.

If you liked this post, you might like to read how our own Aimee Knight went from figure skater to engineer in “I Look Like An Engineer” by Aimee Knight.