Integrating with SendGrid

Question

Can someone help me understand what SendGrid actually adds to an application architecture? Is it's role really as limited as being an alternative delivery engine (SMTP) and post-send analytics? I was hoping that it would do more for transactional email, but everything that I see/read indicates that this is the limit.

My primary use case is for transactional email (new registrations, contact requests, etc.). I'd really like to hear how others have deployed SendGrid within the context of their own web applications. Your experiences may help me better understand how I can best deploy it within my own.

Thanks.

Answer 1

If your primary use case is for transactional email, then SendGrid is the right solution for you. It is essentially a drop in replacement for your SMTP, but will scale way better than you could building something yourself from the ground up. It takes time to setup your own SMTP and time to make sure it's not falling over and sending out emails that never get to their destination.

All SendGrid does is email, so all the heavy lifting and boilerplate tedious setup is done for you. You mention transactional email, that is SendGrid's sweet spot. They make sure email gets where it's supposed to go. The big bonus is they give you a lot of tracking goodies along with making sure your email gets where it's supposed to go. There are a number of large companies that said the 15 minutes they spent switching to SendGrid upped their delivery rates substantially.

Unless you love running an SMTP server, instead of building your own product, I'd highly recommend offloading delivery to someone else.

Answer 2

I implemented SendGrid at my last job, and shortly after left that job to go work at SendGrid. At the time, I simply set it up as an SMTP relay, and it took less than 5 minutes.

Scott's answer nailed it, though. We do a lot more than transactional messaging though. We have a newsletter product that you can plug into. A common use case is when a user registers on your site, you send them a transactional Email and fire off an API call to us to add them to one or more mailing lists based on their opt-in preferences. Then, whenever you want to send an Email to your users, you send us a single message via API with the name of the list, and we take care of delivering it on your behalf. We also help with unsubscribes -- eg. if a user unsubscribes from any message, we can use that event to trigger a call back to your site so you can handle anything on your end as well like un-selecting an opt-in checkbox the next time they view their user profile. I know several small businesses run by friends who do this exactly, including my last job who set this up after I left that company.

Another common setup is having one IP address for your transactional Email, and another IP for newsletters. This way if users flag a newsletter as spam (because they're too lazy to click an unsubscribe link, for example), it won't hurt the reputation of the transactional Emails getting through.

Don't hesitate to contact us with questions. We love to help!