API Reference
API Reference
GitHub
Getting Started

Introduction

What is Mailyard and why use it

Mailyard is a self-hosted email delivery platform that gives developers full control over their email infrastructure. It provides a developer-friendly REST API for sending emails, managing templates, tracking delivery, and monitoring analytics — all without relying on third-party services like SendGrid or Mailgun.

What is in it

Getting mail out. A REST API for single, templated and batch sends, with scheduling , automatic retries and a log of everything that went. An SMTP submission listener for applications that speak SMTP rather than HTTP.

Deciding how it leaves. Servers grouped into pools with failover inside one attempt, a shared pool an administrator maintains for projects with no server of their own, Amazon SES as a provider rather than as a relay, and relay nodes that put egress on machines elsewhere.

Content. Templates that are versioned and localized, with a draft you can preview and activate independently of what is live, and stylesheets inlined at render time because mail clients discard a style block.

Audience. Subscribers with custom fields, static lists and rule-based segments , and campaigns that render per person, throttle, pause and split-test .

Reputation. Domain verification with SPF, DKIM and DMARC, refusal to send from a domain this project has not proved it owns, bounce intake from return paths and feedback loops, and suppression that is scoped where it should be scoped.

Knowing what happened. Open and click tracking , webhooks with signatures and a delivery log, analytics , and Prometheus metrics .

Mail coming in. An MX listener for verified domains, checking SPF, DKIM and DMARC at ingest, and a sandbox that captures rather than delivers — decided by the credential, so a test suite cannot mail a real customer by getting one flag wrong.

Who may do what. API keys , sessions, passkeys , TOTP , OIDC , and per-project roles each project writes for itself out of a fixed permission catalogue — there are no built-in roles to work around.

Running it. A console for all of the above, an admin area for platform settings, users, the shared pool and certificates including an internal CA, and scaling by putting more nodes behind one queue. | Data portability | Project export and bulk erasure | | Prometheus Metrics | Built-in observability for production monitoring |

API Reference

The binary writes its own OpenAPI description:

mailyard export-api-spec --out openapi.yaml

Feed it to Postman or a client generator, or browse it rendered at API Reference . These docs are served at /docs on the same instance.

Architecture

One process is the whole system. The API, the console, the SMTP listeners and the delivery worker all run inside it, and PostgreSQL is the only thing it talks to.

┌─────────────┐     ┌──────────────────────────────┐     ┌──────────────┐
│  Your App   │────▶│  mailyard serve              │────▶│  PostgreSQL  │
│  HTTP / SMTP│     │  api + console + smtp in     │◀────│  data +      │
└─────────────┘     │  delivery worker         out │     │  queue       │
                    └───────────────┬──────────────┘     └──────────────┘
                            ┌──────────────┐
                            │  SMTP Server │
                            └──────────────┘

The queue lives in the emails table. When one process is no longer enough, run several against the same database: every node claims from that one queue, and each claim takes a disjoint batch. See Scaling out .

Next Steps