Skip to main content

We use transactional emails to send out calendar invites. Currently this is working as expected however there is a good UX improvement for the customer that involves setting custom headers so that the email client can be informed that the attachment is an ICS file and to automatically added it to the user’s calendar. 

In order to get the email client to parse correctly the attached .ics file, you should add the scheduling method and MIME information to the email headers. This is specified by the iCalendar Message-Based Interoperability Protocol (RFC 2447).

For this reason, the email header should include Content-Type, Content-Transfer-Encoding and Content-Disposition as specified in the following example:

Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=invite.ics'
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename=invite.ics

 

Why does customer.io not support this? This limitation with customer.io means that we would need to look at another email provider for these transactional emails which just adds another layer of complexity to our tech stack which should be avoided. 

A response from customer.io

Thanks for reaching out with this idea/feature request. This was actually brought up by another customer recently and we looked into the options here, so happy to go into a bit more detail with you.

Firstly, this isn’t something that we are able to support via our current integration with our default Email Service Provider.

With the way we send our messages to our default ESP (Mailgun) today, it doesn’t look like we’re able to modify that header. We do support method=REQUEST now in the header, but only when sending using a custom SMTP integration, because for those we send the full MIME body from our side. (https://customer.io/docs/use-your-smtp-server/)

For our default ESP integration, we send the metadata via their API in pieces and they assemble the body for us. It’s not currently possible to specify the Content-Type using the /messages API that we currently make use of.

Reply


Terms & ConditionsCookie settings