Transactional email control plane

API-first sending workflow with practical SMTP relay handoff.

Wesend accepts API requests, persists outbound messages, pushes them through an SMTP relay, and keeps the operational status visible from the public product surface through the internal app.

Create account Sign in View features

API-first Queue-backed SMTP relay handoff Internal visibility

Request intake

Project-scoped outbound acceptance

Use API keys per project and keep idempotent request handling tied to a stable message ID.

Delivery lifecycle

Accepted to handed off

Track the actual queue and relay lifecycle without pretending relay acceptance is final inbox delivery.

Inspection

Operational detail stays in the app

Messages, domains, API keys, health, and settings use the same control-plane composition.

Developer flow

Contained API surface with visible lifecycle states.

Keep the code sample, queue states, and product explanation in one compact surface instead of spreading them across text-heavy sections.

accepted queued handed_off

POST /api/emails

curl -X POST https://wesend.fklavye.net/api/emails \
  -H "Authorization: Bearer ws_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Wesend <noreply@example.com>",
    "to": ["user@example.com"],
    "subject": "Hello from Wesend",
    "html": "<p>Hello</p>",
    "text": "Hello"
  }'

{
  "id": "msg_xxx",
  "status": "accepted",
  "queued_at": null,
  "handed_off_at": null,
  "failed_at": null
}

Lifecycle note

Queue workers advance delivery

`accepted` becomes `queued`, then `handed_off` or `failed` depending on SMTP relay execution.

Product honesty

Useful now, still incomplete

Webhooks, analytics, templates, attachments, and complete domain enforcement are still outside the current product slice.

Core value

Three product surfaces working together.

Landing, auth, and app now describe the same control-plane model with shorter copy and stronger card grouping.

API intake

Accept outbound mail requests cleanly

Structured request handling, explicit sender fields, project ownership, and stable public IDs keep the send path predictable.

Relay handoff

Use SMTP as the real delivery path

Queue workers perform the relay submission and record the result without hiding configuration or runtime limitations.

Visibility

Inspect the lifecycle from the app

Operational pages keep message status, event history, sender posture, and readiness checks inside the same dashboard shell.

How it works

Compact flow, not a documentation dump.

The current Wesend phase stays focused on acceptance, queue processing, relay submission, and inspection.

Send

Post an outbound email payload through the API with recipients, content, and optional idempotency handling.

Queue

Workers claim accepted messages, mark them queued, and attempt relay submission through configured SMTP credentials.

Inspect

Open the internal app to review event history, sender-domain posture, relay outcomes, and failed delivery signals.

Product maturity

Built as a calm control-plane, not an over-claimed platform.

What exists

API, queue, relay, and inspection

Public product pages lead into a protected app where messages, domains, projects, API keys, and health diagnostics stay visually related.

What is next

More depth, same product direction

Analytics, webhooks, templates, inbound processing, and richer domain enforcement remain future work and are not being disguised as finished.