advanced email templates

This post is directed at the developer who wants to get the most out of SparkPost’s email template capabilities. It is assumed you are comfortable with reading JSON content and following basic programming flow. As terms that maybe new to you are introduced like RFC 5322, the text is linked to its source reference. With that out of the way, let’s jump right in.

SparkPost’s template and transmission capabilities make sending emails straight forward. Those capabilities provide an abstraction for text and HTML content which means most times there is no need to directly encode the raw email format which is defined in RFC 5322 formerly known as (RFC 822). But sometimes you may want to create more complex messages that have other Multipurpose Internet Mail Extensions (MIME) parts that are not directly exposed via the SparkPost’s RESTful interface.

Simplified Email Composition

First, let’s review a sunny day scenario for sending an email. Use the transmission endpoint to provide the text and HTML content. Behind the scenes, SparkPost takes care of composing a valid RFC 5322 email. SparkPost will insert substitution variables from substitution_data into the text and HTML content. This is a powerful way to generate custom content for each recipient in a common template.

Here is an example transmission with HTML and text content with substitution_data.

 

Substitute Arrays of Data 

Many folks realize that SparkPost’s transmission and template endpoints can do simple content substitution in email headers and email bodies. But many overlook the ability to provide conditional content or arrays of data that can be substituted as well. You can also provide unique content per recipient. In this example we send an array of unique links to each recipient.

This is accomplished by providing a JSON array of data that will be populated into the email body. Once the data is provided SparkPost will use logic in the template to populate it.

In this example SparkPost will look for substitution data called “files_html” and do a “for each” on each element in the array. It will create a row with the value of “file” in the “files_html” element. Note the triple curly around “loop_var.file“. This is because each element of the array contains HTML and we need to tell the server to use it as is and not escape it. The text part will be a simple text label and the URL to the file.

Here is the completed working example:

Pro Tip: In your code it is advisable to keep the view markup separate from the data but the goal here was to keep the example as simple and easy to follow as possible so we created two arrays. One array is for HTML part and the other is for the Text part. In production use it would be common to have one set of data and write the logic in the template code.

Attachments in Transmission Capabilities

The transmission endpoint also provides an abstraction for sending attachments. Below you will see attachments are specified in the content.attachments array where each object in the array describes an individual attachment item. Just as before SparkPost will take care of encoding text, HTML, substitutions and iterating through the attachment array to encode a properly formed email message.

Best practices dictate that sending attachments is best avoided unless explicitly required as part of your service.

name type
type The MIME type of the attachment
name The filename of the attachment
data Base64 encoded file data

This is what an attachment looks like inside transmission content stanza:

You can also send “inline images” in a transmission. These are very similar to attachments and are specified in the content.inline_images array where each of the inline_image objects are similar to the attachment object shown above.

Attachments in Templates

Now that we have the proper background for sending attachments with the transmission endpoint let’s take a look at how to do this with templates. At the time of this writing, there is no attachments abstraction like you find for inline transmissions. One might conclude that templates can’t be created with attachments. You would be partially correct but there is a work around, although you will no longer be isolated from the RFC 5322 format.

You can accomplish attachments in templates by encoding RFC 5322 content yourself which includes the attachments. The good news is you won’t lose the ability to still use Substitution Data in your email headers, HTML and text parts. Be aware that this type of template limits the substitutions to the headers and the first HTML and first text part.

Here is an example of how it is done.

RFC822 Email

Create your RFC 5322 email with the substitution data you want. I created this one in my mail client and sent it to myself. Once I received it I copied the source and replace the fields I want to dynamically substitute.

The last MIME part in this message you will see Content-Disposition: attachment; filename=myfile.txt”. That is where the name of the file is defined. Your attachment content will most certainly be much more complex but this example is trying to keep it simple.

Stored Template

Once you have a valid RFC 5322 email store it using the email_rfc822 form of the template endpoint instead of using text and HTML fields. Here is an example of what the content looks like for that message:

When the request completes, SparkPost will respond with a unique identifier for your new template. For example xxxxxxx.

Sending the Template

The good news is that creating the RFC 5322 content was the hard part. From here on out sending that template with SparkPost is exactly the same as sending any other template.

Here is how we send that template and populate the substitution data:

Templates from a Mail Client’s API

If you are using a programming language that has a library for composing an email, you can use that to programmatically create the template or even send the message inline. Here is an example of using JavaMail to do that very thing through SparkPost’s transmission endpoint. This method should be easily translated to PHP or your language of choice.

Conclusion

Now that you see how SparkPost can be used to send email of almost any complexity you may want to have a look at “SparkPost Supports Sending Email on Apple Watch” or have a look at the substitution syntax to see how it can be used with “if then else”, “expressions in conditionals” or “array Iteration” right inside your template or transmission content.

This blog post was inspired by a question from one our of our fantastic community members who went on to write the SparkPost C Sharp library. If you want to get deeper with SparkPost, I encourage you to join the conversation in the SparkPost Community Slack Channel. You can also connect with us through the SparkPost development hub and on Twitter.

-Chris

If you liked this post, be sure to check out Automatic CSS Inlining with SparkPost

Blog-Banner-WeHeartDev_600x150-030416

css inlining

TL;DR – add "inline_css": true to your Transmission Options object.

If you’re reading this blog, you probably know a thing or two about email. What’s tricky about email is that there are more than a few things that need to be just right in order for your customers to be able to interact with what you send them. One of those things is CSS inlining, and it affects how your HTML email is rendered in many email clients – is that white text on a blue background, or is it invisible?

Why Inline?

The easiest way to understand why CSS inlining matters is to think about how a web-based email client displays HTML messages. In that scenario, the email client itself is built in HTML, and is already using CSS for various things. So how can the email client display HTML messages, without allowing the style rules within each message to affect the display of the email client itself? The simplest and most consistent approach is to remove any CSS rules, which leaves only style attributes on each individual HTML tag, AKA “inline styles.” This is the approach that many email clients take, especially web-based email clients.

So that’s the “why” part of CSS inlining. What about how? As mentioned in another recent blog post, SparkPost runs on the Momentum platform, which includes several libraries that make the inlining process easier. CSS inlining has been on our radar for a while, which included building several proof-of-concept implementations, with a variety of approaches. We’ve recently received lots of requests for this feature, which bumped its priority on our roadmap. Voilà!

How to Enable Inlining with SparkPost

Enabling automatic inlining is a simple change – add "inline_css": true  to your Transmission Options object, and send as usual. We didn’t see a significant increase in generation time during our performance testing of this feature, however it is possible that your special CSS may cause generation to take longer than usual.

Inlining and Advanced Templating

SparkPost offers templating features that can change the structure of HTML messages, such as conditional content ( if / then / else ) and dynamic per-recipient content. Our CSS inlining is fully compatible with these templating features, since inlining happens for each individual message, after template processing has been completed.

Selector Support (CSS1, CSS2, CSS3, Oh My!)

There are lots of types of CSS selectors, and they can also be combined so that, for example, the color of an element changes based on the element(s) that contain it. SparkPost’s CSS inlining support covers most common usage for email, with the following exceptions:

From CSS1, we do not support:

  • ::first-letter
  • ::first-line
  • :active
  • :focus
  • :hover
  • :link
  • :visited

From CSS2, we do not support:

  • :first-child
  • :lang

Some of these are excluded because it is impossible to support them correctly ( :active , etc). Others because they are simply shortcuts – p:lang(en)  can also be written p[lang="en"] .

Support was also added for some CSS3 attribute value comparison operators:

  • [attribute^="value"] – “begins with”
  • [attribute$="value"]  – “ends with”
  • [attribute*="value"]  – “contains”/”substring”

Did we miss your favorite CSS selector? Which one, and how have you used it with email?

Have you been inlining for ages? How can we make your workflow easier?

Or did the world just become a little more complicated when you learned that CSS inlining was a thing?

Come chat with us on Slack or Twitter, and let us know what you think.

-Dave

If you liked this post, check out Advanced Email Templates

Blog-Banner-WeHeartDev_600x150-030416