Ruby on Rails quickstart

Point ActionMailer at sendvia's SMTP relay, send one email, and find it in your send log. Requires the paid SMTP add-on.

Get an API key

Create a sendvia account and a key is issued immediately, sitting on the Account page, prefixed sv_live_. Every example below writes it as a placeholder:

sv_live_xxxxxxxxxxxxxxxxxxxxxxxx

You also need a domain verified in your account, since the mail below is sent from an address on it. Add one under Domains if you have not already, and give its DNS records time to propagate.

Send one email

ActionMailer already speaks SMTP, so this is a settings change, most often in config/environments/production.rb or an initializer.

config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:              "smtp.sendvia.io",
  port:                 587,
  user_name:            "sendvia",
  password:             ENV["SENDVIA_API_KEY"],
  authentication:       :plain,
  enable_starttls_auto: true,
}

user_name accepts anything; sendvia authenticates on the password alone, which is the API key above, best kept out of source control as an environment variable. If a network blocks port 587, set port to 2525 instead and nothing else changes.

ActionMailer::Base.mail(
  from:    "[email protected]",
  to:      "[email protected]",
  subject: "Hello from sendvia",
  body:    "This is a test email sent through sendvia."
).deliver_now

deliver_now raises on a connection or authentication failure, but a clean return does not by itself prove the message went anywhere: sendvia can still refuse it after accepting the SMTP session. The next step confirms what actually happened.

See it in the log

SMTP sends land in the same send log as API sends, tagged with an SMTP badge so the two are easy to tell apart. Check the History page, or query the API directly with the same key:

curl "https://api.sendvia.io/v1/[email protected]" \
  -H "Authorization: Bearer sv_live_xxxxxxxxxxxxxxxxxxxxxxxx"

{
  "total": 1,
  "limit": 25,
  "offset": 0,
  "logs": [
    {
      "id": 42,
      "to_address": "[email protected]",
      "from_address": "[email protected]",
      "subject": "Hello from sendvia",
      "status": "delivered",
      "error_message": null,
      "sent_at": "2026-08-20 10:03:01",
      "delivered_at": "2026-08-20 10:05:01"
    }
  ]
}

The row moves from queued to sent within moments of the relay accepting it. Read the status after that carefully: sendvia never receives a delivery confirmation from the recipient's mail server, over SMTP or the API. Two minutes after a clean send it marks the message delivered on its own, an inference from the absence of a bounce rather than a receipt. A real bounce or failure overwrites that status the moment one arrives; nothing plays the same role for an honest delivery. Logs like this stick around for 7 to 90 days, depending on your plan.

Troubleshooting

Neither failure below raises an exception ActionMailer will show you: the relay accepts the SMTP session either way, and sendvia's own checks decide what happens to the message behind it. The log is where you actually see which one you hit.

The SES sandbox rejects your test recipient

A new SES account starts inside Amazon's sandbox: 200 emails a day, sent only to recipient addresses you have verified yourself in the SES console, pending an AWS review that usually takes 12 to 24 hours. Send to any other address while sandboxed and the log shows status: "failed" with AWS's own rejection reason sitting in error_message, the same as it would for a send through the REST API.

Verify the test recipient in the SES console while you wait, or request production access, which lifts the restriction for every recipient at once.

The domain has not been verified

sendvia checks the domain on the from address against the domains verified on your account, the same rule the REST API enforces as a 422 before it ever calls AWS. Get that wrong, typically by mailing from a domain you have not added yet, and the message never leaves. There is no response body to read the way a REST call gives you one, so confirm the domain's status directly on the Domains page rather than guessing from the Rails console.

Add the domain if it is missing, publish the DNS records sendvia gives you, and resend once the check passes.