A continuation of the landing page: compact, card-based, and aligned to the same control-plane tone rather than a plain text inventory.
Each area below maps to the current Wesend phase: intake, queue processing, relay handoff, and operational inspection.
Accept structured transactional email payloads through `POST /api/emails` with idempotency support and project ownership.
Issue hashed project-scoped API keys for sending and message-status reads without exposing plaintext tokens after creation.
Workers claim accepted messages, write queue state changes, and drive the runtime path toward relay handoff or failure.
Queued messages are submitted through configured SMTP credentials and successful relay acceptance is stored as `handed_off`.
Inspect `accepted`, `queued`, `handed_off`, and `failed` states from the API and the authenticated internal message surfaces.
Review timeline events like `message.accepted`, `message.queued`, `message.handed_off`, and `message.failed` with timestamps and payload data.
The internal app now follows the same visual system across messages, projects, domains, API keys, health, and settings.
Review delivery status, sender posture, timestamps, and event timelines with a stronger list-detail hierarchy.
Manage project settings, sender-domain records, verification posture, and API key issuance inside consistent content cards.
Read relay readiness, queue expectations, domain posture, and next-phase system settings from the same dashboard shell.
The UI is more product-like, but the product messaging still stays honest about what remains unfinished.
Domain records and manual verification are available, but full send-time enforcement is still partial.
Open, click, bounce, and webhook pipelines are still outside the current Wesend product slice.
Wesend currently focuses on direct payload submission, not template rendering or attachment management.
The present product direction remains outbound control-plane functionality rather than inbound processing.