Transend

An open, developer-first transactional email API — send emails, verify sending domains, manage credentials, and inspect delivery activity over a clean HTTP API.

4 min

Transend - Email delivery without the drag

Transend is a transactional email platform built as an open, developer-first alternative to Resend. It gives developers a clean HTTP API for sending email, verifying sending domains, managing API credentials, and inspecting delivery activity — backed by a Rust server and AWS SES for delivery.

The goal: make sending transactional email feel like one simple API call — no SMTP wrangling, no deliverability guesswork, no vendor lock-in.

Web App · GitHub · Status

Tech Stack: Rust · Axum · SQLx · PostgreSQL · AWS SES · Nuxt 4 · TypeScript · TailwindCSS · Docker


One Request to Send

Send email with a standard JSON payload and a Bearer API key:

curl --request POST \
  --url https://api.transend.email/v1/emails \
  --header "Authorization: Bearer tsd_live_your_api_key" \
  --header "Content-Type: application/json" \
  --data '{
    "from": "hello@mail.example.com",
    "to": ["you@example.com"],
    "subject": "Hello from Transend",
    "html": "<h1>It works.</h1>"
  }'
{
    "id": "01972e64-c32c-7ac9-9929-191cf71e26a4"
}

Core Features

CapabilityWhat it gives you
Sending APISend one email or submit a batch over HTTPS.
Domain VerificationAdd a sending domain and verify its DKIM records.
API KeysSeparate credentials for production, staging, and local.
WebhooksRegister endpoints for delivery events.
DashboardNuxt 4 app for domains, keys, and delivery activity.

Architecture

The backend is a Rust workspace, split into focused crates so domain logic stays pure and I/O lives at the edges:

transend/
├── crates/
│   ├── transend-core/           shared domain types (no I/O)
│   ├── transend-mailer/         Mailer trait + AWS SES implementation
│   ├── transend-db/             sqlx queries + migrations
│   ├── transend-identity/       auth, API keys, sessions
│   ├── transend-notifications/  webhooks & delivery events
│   ├── transend-api/            Axum HTTP server (the thing you deploy)
│   └── transend-cli/            dev CLI — send test emails, admin tasks
│
└── web/                         Nuxt 4 frontend (marketing + dashboard)

Design decisions:

  • Trait-based mailer — delivery is behind a Mailer trait, so AWS SES is an implementation detail. Other providers can be added without touching the API layer.
  • Compile-time checked SQLsqlx validates every query against the live Postgres schema at build time.
  • Core crate has zero I/O — shared domain types are dependency-free, keeping business rules testable and portable.

Tech Stack

Backend: Rust · Axum · Tokio · SQLx · PostgreSQL · AWS SES

Frontend: Nuxt 4 · TypeScript · Nuxt UI · TailwindCSS v4 · TanStack Query

Infrastructure: Docker · VitePress (docs)


Status & What's Next

Status: In active development. Sending API, domain verification, API keys, and the dashboard are built; deliverability tooling (SPF/DKIM/DMARC guidance, BIMI) and a Rust SDK are in progress.

  • Rust SDK (sdks/transend-rust) for typed, ergonomic integration
  • Delivery event webhooks with signed payloads
  • Batch sending and template support

What I'm Learning Building Transend

  1. Email is an infrastructure problem disguised as an API problem — deliverability, DNS, and reputation are the real product
  2. Rust's type system shines in billing-adjacent systems — making invalid states unrepresentable matters when every send costs money
  3. Crate boundaries are architecture — separating core types from I/O forced cleaner design than any style guide could
Spread the word