Introducing SendGridForEpi

Open sourced packages that helps you sending mail from Episerver using SendGrid's API and transactional templates.

I'm fairly certain most readers are familiar with SendGrid but I suspect most of you are just using their regular SMTP interface to send e-mails. This would be the typical setup when running Episerver on Azure or DXC Service.

If you have access to the SendGrid app it's very powerful to instead use the transactional templates and post mails through their REST API. This allows you to send to multiple recipients in one remote call and SendGrid will help you with the delivery timing to avoid being blacklisted. It's also very easy to hook up your own subdomain names for template images and click tracking; features that are unavailable when sending by SMTP.

Within a transactional template ID you also have the option switch between different template versions and of course you work with substitutions to personalize.

SendGrid's template editor is pretty decent as well and you can choose to have your own substitution variable syntax. You have the option to post a complete body or smaller more focused variables as part of a Personalization object.

My SendGridForEpi package will help you by storing new Mail objects in a SQL Server table which later is processed by a Scheduled Job that does the actual posting to SendGrid's REST API. Your code could look something like this:

var mail = new Mail
    From = new Email(""),
    TemplateId = "cf6d9ac4-****-480b-a95a-77921d060261"

    new Personalization()
        Tos = new List<Email>
                    new Email("")
        Substitutions = new Dictionary<string, string>
                    { "{whoIs}", "Some Dude" },
                    { "{commentText}", "A <b>bold</b> comment" }

this.mailService.AddToQueue(new MailQueueItem
    Date = DateTime.UtcNow,
    Mail = mail

The included Scheduled Job:

Benefits with this setup:

  • Nothing gets lost even when SendGrid can't be reached or your Mail object can't be posted. Latest error message and number of attempts is kept on the item.
  • Should be faster and more reliable than a HTTP or SMTP call in your user flow.
  • Completed items are archived to log table which can be used for statistics.

The repo README at Github should have all you need to get started and try it out. Please check the code and hit me with some pointers and comments!

Published Tuesday 21 February 2017 23:02 and tagged with these categories: Episerver, ASP.NET


  1. Ted Nyberg Thursday 23 February 2017 07:49

    Nicely done! Is the queue stored in DDS or in a custom table?

  2. Author Comment Thursday 23 February 2017 07:55

    Thanks Ted!

    Two custom tables are created when site initializes (happens inside the SqlServer package). You also have the option to put them in another database than the the Epi db.

    It's quite easy to implement your own IMailService if you need something else. The case I see for other types of storage could be being able to put on the same queue from some completely different app but get processing from the Epi job.

    Plan is to add a third package where the archive table will get rows moved to an Azure Table Storage so that the SQL Server table doesn't get massive. I will also fix some report/status UI.

Add Your Comment