Newsletters in Aamu.app bring the subscriber list, reusable email design, individual issues, sending, and automation into the same project workspace. A team can prepare a publication without moving contacts to one service, designing the message in another, and reconnecting the workflow through a collection of integrations.

Each newsletter is project-scoped. Its issues, subscribers, template, sender settings, and API access follow the same team and project boundaries as the rest of the work in Aamu.

One place for the whole publishing workflow

A newsletter has four practical areas: Issues, Subscribers, Template, and Settings. Issues are the messages you prepare and send. Subscribers are the recipients and their subscription state. The template defines the reusable content structure and outer email design. Settings connect the newsletter to a verified sending domain and mailbox.

The newsletter name is edited directly where it is used. A new unnamed newsletter opens the name field automatically, and an existing name can be clicked to edit it. Sender details do not need to be duplicated: the visible sender name and email address come from the selected mailbox's Sender name and Address.

Subscribers remain explicit

Subscribers can be added individually or imported from CSV. Each subscriber has a clear subscribed or unsubscribed status, so an address can be removed from active delivery without losing the history or contact record. An unsubscribed contact can also be subscribed again when there is a valid reason to do so.

Every delivered message receives a subscriber-specific unsubscribe URL on the team's own hostname:

https://{team}.aamu.app/newsletter/unsubscribe/{subscriberId}/{token}

The public confirmation page keeps the result deliberately simple: the recipient sees that they have been unsubscribed and will no longer receive the newsletter.

Publish a signup form with Aamu Forms

The Signup form tab creates a public, editable Aamu Form for the newsletter. The form starts with email and name fields, but it remains a normal Aamu Form: the team can edit its title, description, fields, visual theme, public URL, thank-you page, and custom CSS.

Publishing the signup form also creates its backing Database and a row_inserted automation. Each form response remains in the Database as submission and consent history. The automation then upserts the normalized email address into the newsletter's canonical subscriber list.

This avoids making the Form Database a second delivery list. The Database records what was submitted and when; newsletter_subscribers remains the source of truth for whether an address currently receives the newsletter. Repeated submissions update the existing subscriber instead of creating duplicates.

A reusable template with deliberate placeholders

The content template defines the repeatable structure editors see when they create an issue. It contains one issue-content area and one unsubscribe element. This prevents an essential compliance link from becoming an afterthought in each new message.

The wrapper controls the surrounding email HTML. It contains exactly one {{CONTENT}} placeholder for the rendered issue and can use {{SUBJECT}} where the subject belongs. Keeping content and wrapper separate makes it possible to adjust the publication's shared visual frame without rewriting every issue.

Test the real message before sending

An issue starts as a draft with a subject and HTML content. The preview combines the issue with the current newsletter template and wrapper, so the editor can inspect the actual message structure before delivery.

Send test uses the signed-in user's email when that address is an active subscriber. This is intentional: the test message gets the same subscriber-specific unsubscribe link as a production message. Testing therefore covers the link that recipients will really use, not a special placeholder URL that behaves differently.

Sending is explicit. Send test sends one test message; Send delivers a draft issue to active subscribers and marks it sent. While either operation is running, its button is disabled and shows Sending..., preventing accidental duplicate clicks.

Mailbox configuration stays in the UI

Before messages can be sent, the newsletter needs a mailbox based on a verified email domain. Choose the domain, set the mailbox address, and set the sender name in Aamu. The newsletter then uses that mailbox consistently for test and production delivery.

Mailbox provisioning is intentionally not part of the Newsletter API. Domain verification and sender configuration remain an administrative UI step, while routine publication work can be automated after the mailbox is ready.

Automate newsletters through the API

The project-scoped Newsletter API can list, create, and update newsletters; create the signup Form–Database–Automation workflow; create and edit draft issues; manage subscribers; send a test; and explicitly send a production issue. Requests use a Team API key with the Newsletters scope and the project header.

x-api-key: YOUR_API_KEY
x-project-id: YOUR_PROJECT_ID

A simple automated flow can create a newsletter issue from approved content, add or synchronize subscribers, send a test to the API actor, and leave production sending as a separate action. Subscriber API responses never expose unsubscribe tokens.

POST /api/v1/newsletters/{newsletterId}/issues
{
  "subject": "June product update",
  "html": "<p>What changed this month...</p>"
}

POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/send-test
POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/send

The signup workflow is created idempotently. The first request creates the resources; later requests return the same connected form and automation:

POST /api/v1/newsletters/{newsletterId}/signup-form

The separate send endpoints matter for AI and other automations. Creating or revising a draft is reversible; delivering email to a list is an external side effect. Aamu keeps that boundary visible instead of treating every content update as permission to publish.

For the complete endpoint overview, authentication model, and examples alongside the rest of the platform, see Building with the Aamu API.

A newsletter that belongs to the workspace

The useful part of Newsletters in Aamu is not merely sending an HTML email. It is keeping the publication close to the project that produces it: the Docs that contain source material, the tasks that coordinate a release, the database rows or forms that collect information, and the people responsible for reviewing the final message.

The result is a compact publishing workflow with explicit subscribers, reusable design, realistic testing, safe unsubscribe links, and an API that can automate the repetitive parts without hiding the moment when a message is actually sent.