A Simple Recipe for Scheduled Mailings

Do you need to send batches of emails, synchronized to go at a set time? Are you unsure whether to develop your own campaign management tools, or buy off-the-shelf? Have you been through our Getting Started Guide, and are inspired to send your first campaign, but are feeling a bit nervous about writing your own code?

A customer of ours recently had this same need: sending out email batches of a few million emails each morning. Fully-featured campaign management tools from SparkPost partners such as Iterable, Ongage, and Cordial handle this task (as well as much more complicated scenarios) easily. When you have many different campaign types, triggered emails, complex “customer journey” campaigns, and integrated WYSIWYG editors, sophisticated marketing tools are essential.

If, however, you’re just looking for something plain and simple (and don’t mind getting your hands dirty with a little code), there is another way. And for that you’re in the right place! SparkPost’s Python library and our built-in scheduled sending feature make it easy to put something together.

We’ll put ourselves in the shoes of our friendly fictional company, Avocado Industries, and follow them through setting up a campaign. This article takes you through various features of SparkPost’s Python client library, and links to the final code here.

So What Do I Need?

You’re sending out a newsletter to your subscribers. You’ve created a nice looking template and uploaded it to SparkPost. You have your recipient list at hand, or can export it easily enough from your database. You want SparkPost to mail-merge the recipient personalization details in, and get your awesome send out.

These needs translate into the following design goals for the code we’re going to write:

  • Specify everything about your send using parameters and a small text file. You don’t want to change the code for each campaign.
  • Leverage the SparkPost stored template and personalization features, without doing any programming yourself.
  • Use local flat files for the recipient lists. The same format used by SparkPost’s stored recipient list uploads is a good fit.
  • Gather recipients from your list into API-call batches for efficiency, with no upper limits to the overall size of your send.
  • Support timezones for the scheduled send, and also support “just send it now.”

Data Guacamole

The SparkPost recipient-list format looks like this, with all the fields populated. Here we see Jerome’s details for the Avocado Industries loyalty scheme. We can see he’s a gold-card member, lives in Washington State, and likes several different avocado varieties.

Everything apart from the email address is optional, so it would be nice to have the tool also accept just a plain old list of email addresses.  It would also be nice if the tool is happy if we omit the header line.  That’s easily done.

Taco Me To The Start

The tool is written for python3.  SparkPost relies on the pip installer, and we’ll need git to obtain the tool.  You can check if you already have these tools, using the following commands.

If you already have them, continue to “Add SparkPost Python Library sauce” below.  Otherwise here is a simple install sequence for Amazon EC2 Linux:

If you are using another platform, check out installation instructions for your platform here.

Add SparkPost Python Library Sauce

We use pip3 to install, as follows.

Get the sparkySched code from Github using:

Gotta Be .ini To Win It

We now set up some attributes such as your API key, campaign, and certain substitution data in a text file, as they will be the same each time you send. An example is provided in the project called sparkpost.ini.example. Rename this to sparkpost.ini, and replace <YOUR API KEY> with a key you’ve created in your own SparkPost account.

And, Send!

There’s a sample file of 1000 safe test recipients included in the project that we can send to.  Change the template name below from avocado-goodness  to one you have in your account, and set the sending time to suit you:

If all is well, you should see the “OK” line, and your mailing is sent.  That’s all you need to do.  Happy sending!

Code Salsa

In this section, we take a deeper look inside the code.  You can skip this if you just want to use the tool instead of changing it.  Here’s how we call the SparkPost API to send messages, using the SparkPost Python library:

After some helpful on-screen output about what we’re trying to send, the function composes the recipients with the other passed-in ingredients and mixes in some sensible defaults, using sendObj.update().

The SparkPost library call is wrapped in a try/except clause, as it can return errors at the application level (such as having an incorrect API key), or at the transport level (such as your Internet connection being down). This is generally good practice with any code that’s communicating with a remote service, and follows the examples packaged with our library.

We use startT, endT, and the time()  function to measure how long the API call actually takes. While not strictly necessary, it’s interesting to see how performance varies with batch size, routing distance from client to server, etc.

We will now craft the code to read parameters from the .ini file and use them in the API sends. Let’s read and check the mandatory parameters:

The Python library configParser does the heavy lifting. You’ve got to have an API key, so we exit if unset. baseUri defaults to the sparkpost.com API endpoint if it’s unset. The other parameters from the .ini file are read in the same way, and are described in the project README file.

There are other ways to set things up in Python, such as using environment variables. My preference is for .ini files, because the file is right there, staring at you. It’s easy to store, communicate, change and check, right there in your project.

Chickens Go In, Pies Come Out …

Let’s look at how to read that .csv format recipient list. Python provides a nice library, csv. All the reading of double-quoted stuff that .csv files need to carry JSON objects like "{""custID"": 60525717}" is taken care of for us.

We could use csv to read the whole recipient-list into a Python array object – but that’s not a great idea, if we have squillions of addresses in our list. The client will be perfectly fast enough for our purposes, and we’ll use less client memory, if we read in just enough to give us a nice sized batch to cook each time around.

We’ll also handle line 1 of the file specially, to meet our ‘go easy on the optional file header’ requirement. Recall that a well-formed header should look like this:

If it’s got the single word email somewhere on line 1, let’s assume it really is a header, and we’ll take our field layouts from that line.  The tool will be happy if you omit optional fields, or have them in a different order on the line.  The only one you absolutely need is the email field.

We then check if it’s really a headerless file with just a bunch of email addresses in it, by checking for a single entry with an @ sign.

In the main loop for i,h in enumerate(hdr) we use some nice Python language features to conform the data to the JSON object that SparkPost is expecting. The name field needs to be put inside the address.name JSON attribute. Return_path is added, if present. Metadata, substitution_data and tags all come in to us as JSON-formatted strings, so we unpack them using json.loads().

All that’s left to do, is to chew through the list, sending each time we gather in a full sized batch. We send any final batch at the end, and we’re done.

Command-line Garnish – A Pinch Of Thyme Time

The last part we need is some command-line argument parsing. The recipient-list, the template-ID, and the sending date/time are the things you might want to vary each time the tool is run. Python munges your arguments using argv[] in much the same way as other languages.

There are all kinds of nonsense possible with input date and time – such as February 30th, 24:01 and so on. Mix in timezone offsets, so the user can schedule in their local time, and no-one would seriously want to write their own time parsing code! SparkPost’s API will of course be the final arbiter on what’s good, and what’s not – but it’s better to do some initial taste-tests before we try to send.

Python’s strptime() function does mostly what we want. The format string can be made like SparkPost format, except Python has no : separator in the %z timezone. Python’s elegant negative indexing into strings (working backwards from the end of the string) makes it easy to write a small checking function.

Plat Du Jour

If you don’t want to schedule a future start_time, you can just give today’s date and time. Times in the past are sent immediately.

Depending on where your code is running (I happen to be using an AWS virtual machine), you should see each batch get sent in a few seconds. Even though it’s single-threaded, you can schedule a million emails in around ten minutes. The actual send will proceed (at the scheduled start_time) as fast as it can.

And that’s pretty much it. The full code, which is just over 100 actual lines, is here with easy installation instructions.

A Small Digestif …

What’s the best way to test this out for real? A tool to generate dummy recipient-list with sinkhole addresses could be handy. Keep an eye out for a follow-up blog post. I’ve included a couple of ready-made recipes recipient files in the github project to get you started.

Is this your first dining experience with Python and SparkPost? Did I add too much seasoning? Should the author be pun-ished for these bad jokes? Let us know!

– Steve Tuck
Senior Messaging Engineer

P.S. Want to talk more Python with us? Join us in our Community Slack.

Twenty years ago, there was only one web browser and it was actually called the “World Wide Web” browser. There was only one search engine and its name was Archie. About that same time I remember reading about the research team at the Cambridge University’s computer lab where they had a non-computer problem to solve – the department coffee pot was always empty when they wanted a cup.

Being computer science geeks, they of course, found a computer science solution to the problem – rig up a camera and network it so they could always see when the coffee pot was full. That way they could make sure there was going to be coffee in the pot before they made the journey down the hall to fill a cup. This is how the first web cam was born.

What does this have to do with email? When I was thinking of radical, esoteric ways to show how email can be used to automate external processes, guess what I thought of first? Yes, that’s right – coffee. In practical terms, my coffee pot is a flight of stairs away and, like the computer geeks at Cambridge, I too would like to know that there is actually coffee in it before I make the trek. So let’s do this: let’s create a message-driven workflow that will bring some certainty and clarity to the coffee situation in my office.

Getting started:

What we need to make this work is an understanding of the Lua language – don’t worry, I’ll walk you through it. One of the things the Momentum software is very good at is processing mail – accepting messages, doing something with them, and then responding to / delivering messages. It is the “do something” part that we’re going to concentrate on here. In this case we are going to use Momentum’s embedded Lua script engine to check the incoming mail and read the subject line. If the subject line says “Show My Coffee Pot” then we want Momentum to do several things: a) get the current image from my “coffee cam” b) generate a reply email to the sender with c) an image of the coffee pot in it. The web cam watching the coffee pot captures an image every 30 seconds and saves it as a file on the server, so we can just attach that file to the mail and it will always be the current image.

Here’s the Lua script that will enable Momentum to perform our coffee pot check:

— ############################################### —

— load Message Systems helper extensions

require(“msys.core”)

require(‘msys.extended.message’);

 

local mod = {};

 

function mod:validate_data(msg, str, accept, vctx)

— define the variable tables we will need for the message components

local ctx = { ec_message = msg };

local headers = {};

local pparts = {};

local attachments = {};

local subject = msg:header(“subject”);

 

if string.lower(subject[1]) == “show my coffee pot” then

— create a message container and define mailfrom and rcptto

local imsg = msys.core.ec_message_new(now);

local imailfrom = “noreply@c1n1.trymsys.net”;

local ircptto = msg:mailfrom();

 

— define the headers and message parts

headers[“To”] = ircptto;

headers[“From”] = “noreply@c1n1.trymsys.net”;

headers[“Subject”] = “Current image from CoffeeCam”;

pparts[“text/plain; charset=utf8”] = “The CofeeCam image is attached.”;

pparts[“text/html”] = “<b>! CoffeeCam !</b> <br /> Latest image is attached.”;

local files1={};

files1[“type”] = “image/jpg”;

files1[“name”] = “coffee.jpg”;

— load the webcam image to the attachments table

local file_name = “/opt/msys/ecelerity/etc/conf/default/lua/coffee.jpg”;

local io = msys.core.io_wrapper_open(file_name, msys.core.O_RDONLY, 0666)

files1[“content”] = io;

files1[“disposition”] = “inline”;

attachments[1] = files1;

 

— build and send

imsg:build(headers, pparts, attachments);

imsg:inject(imailfrom, ircptto);

end

return msys.core.VALIDATE_CONT;

end

 

msys.registerModule(“coffee”, mod);

— ############################################### —

Toggle Comments »


The above script simply needs to be applied to a current version of Momentum and it will work. Don’t have Momentum? No worries – you can see the result in our demonstration system by sending an email to noreply@c1n1.trymsys.net with the subject “Show My Coffee Pot” and the system will send you back the last available image of the coffee pot. Please note that the script running on this demo system may not be here forever. If it is ever disabled, I will try to remember to update this blog.

So what does this prove? Well, admittedly, the coffee pot example is frivolous and not exactly something to base a business model on, but imagine what you can do in your business if you can enable other processes based on message activity. In this case, we automatically send an image back to an email address based on a matching subject line, but what if we send back an image from a security camera based on receiving an SMS and a security code? Or maybe we could generate an alert message to the system administrator if a particular set of key words were in the body of a message. How about automatically printing off a paper report summarizing mail activity for every 1 million messages delivered? Or getting your bank balance texted to you?

The uses for this kind of automation are endless, and any of the above scenarios would only require minor tweaks to the basic code above. If this sounds like something your business could leverage, I’d be happy to set up a meeting for you with the appropriate people at Message Systems.

(Editor’s note: Please note that Tom’s live coffee cam might not be online 24×7, but emailing to noreply@c1n1.trymsys.net should still return the latest image on the server as outlined above.)