Sending transactional email from Rails without ActionMailer's SMTP defaults

Rails' ActionMailer defaults to SMTP delivery, which is fine for a lot of use cases but gives up the delivery visibility an HTTP API provides: structured bounce data, webhook events, and per-message status you can query. Worth being upfront: there's no dedicated Ruby SDK for Envello yet, unlike Node, Python, Go, and PHP. That's a real gap, not an oversight this post is going to pretend around, and a plain HTTP call covers the actual need with no extra dependency.

Replacing ActionMailer's delivery method

Keep ActionMailer for what it's good at: templating and organizing your mailer classes. Swap out the delivery step itself. Inside a mailer's deliver_now (or a custom delivery method), call Envello's API directly with Ruby's built-in Net::HTTP or a lightweight gem like Faraday, rather than routing through ActionMailer's SMTP adapter:

• POST to https://api.envello.dev/emails with an Authorization: Bearer <ENVELLO_API_KEY> header
• JSON body: { from:, to:, subject:, html: message.body.to_s }, reusing ActionMailer's own rendered HTML as the body
• Check the response status and raise on a non-2xx rather than assuming success

Keeping ActionMailer's templating, dropping its SMTP delivery

This is a smaller change than it sounds like: your .html.erb mailer views, layouts, and mailer classes stay exactly as they are. Only the actual delivery mechanism, the part that currently hands off to an SMTP server, gets replaced with an HTTP POST. ActionMailer's delivery_method config supports a :test or custom adapter pattern if you want to keep the interception cleanly scoped to one place rather than editing every mailer.

If a Ruby SDK matters enough to you

Node, Python, Go, and PHP SDKs already exist in Envello's repo (with varying publish status, none are fully production-published yet either). A Ruby client following the same shape is a reasonable thing to build if the plain HTTP approach above becomes a maintenance burden across many mailer classes, but for a typical Rails app's transactional email volume, a single shared HTTP helper method is usually enough.