Falsehoods programmers believe about email APIs

Engineering ∙

Any sufficiently advanced technology will eventually need to send email. And anyone who runs an email delivery program in production for long enough will eventually discover how difficult it is to simply get email delivered reliably. As the CTO of HubSpot, Dharmesh Shah, put it: “Email deliverability is a multi-billion dollar problem.”

Yet it is one of those problems that I see these young whippersnappers rediscovering for themselves again and again. The journey of [falsehoods believed] usually goes something like this:

  1. Apps don’t need an email API.
  2. My app can just use the Gmail API.
  3. All I need is my Gmail username and password, right?
  4. Gmail’s SMTP API just works.
  5. SMTP just works.
  6. MailChimp is an email API.
  7. Ok, it’s an email marketing tool, but it has an API to send email.
  8. If I Google “email API”, I will easily find one.
  9. If I find one, I can just sign up now and start sending email.
  10. How hard can it be to send a damn email?
  11. After I sign up and decide to choose an email API, I will never change my mind.
  12. If I change my mind later, I can easily switch to another email API.
  13. My email API will deliver all of my email.
  14. My email API will deliver all of my email sent to valid addresses.
  15. If my email API successfully delivered an email to a particular address once, it should be able to deliver it again to the same address with no problem.
  16. If my email API says the email was delivered, it was.
  17. If my email API says the email was not opened, it wasn’t.
  18. If I check my email API logs, I should be able to find an email I sent.
  19. I can read my email API logs.
  20. Status codes returned by SMTP servers, found in email API logs, are well defined.
  21. Oh come on, at least they mean something?
  22. If I check my email API dashboard, I should be able to see the contents of the emails I sent.
  23. If my email API status page reports no current incidents, everything is fine and dandy.
  24. Big name email API’s rarely go down.
  25. If I stop using bad email API X, and choose Y, I will get better service on Y.
  26. I need exactly one email API.
  27. Most apps use exactly one email API.
  28. Wait, why can’t I just use one email API?
  29. I only need two email APIs, one for marketing and one for transactional.
  30. “Transactional” email is well defined.
  31. My email won’t be marked as spam.
  32. My transactional email won’t be marked as spam.
  33. At least my critical emails like password resets won’t get marked as spam.
  34. If someone marks my email as spam, I should still be able to send them critical emails that they request.
  35. I never send spam email.
  36. SendGrid is a good email API.
  37. Mailgun is a good email API.
  38. Amazon SES must be a good email API because it’s Amazon.
  39. Look at all these big logos using Email API X. It must be good.
  40. Postmark is the best email API.
  41. There exists an email API “X”, such that X is the best email API.
  42. Now you’re just being biased, because you built Flute.
  43. Flute is the best email API.
  44. Flute is an email API.

Any sufficiently advanced use of an email API will eventually end up trying to abstract away your email provider, load balance across many of them, and implement retry/failover mechanisms.

Interested in building this? Give us a shout at careers at flutemail.com. Thanks!