Short answer: Create newsletters with a Database-backed audience, manage subscriptions through the UI, Forms, CSV, or API, design reusable templates, and send issues from the same project workspace.
Newsletters in Aamu.app bring the audience, 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. A newsletter workflow is mostly about making sure the right people get the right message—and that nobody accidentally emails the entire planet.
Each Newsletter is project-scoped. Its Audience Database, issues, subscriber projection, 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 six practical areas: Issues, Subscribers, Signup form, Database, Template, and Settings. Issues are the messages you prepare and send. Subscribers shows the current delivery list. Signup form can create a public subscription form. Database opens the underlying audience and its subscription data. 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. Its Audience Database follows the Newsletter name. 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.
The Audience Database is the source of truth
Creating a Newsletter also creates its Audience Database, a Subscribers table, and managed subscribe and unsubscribe automations. You do not need to create a signup form before adding recipients. The Database tab opens the audience directly.
Recipients can be added individually, imported from CSV, collected with an Aamu Form, or written through the Database or Newsletter API. All of these routes converge on the same Database instead of maintaining separate lists. Each row has a clear subscribed or unsubscribed status, so an address can be removed from active delivery without losing its contact or consent history. The Newsletter's subscriber list is a derived delivery projection of these Database rows.
Because the audience belongs to the Newsletter's project, the same email address can have a different subscription choice in another team or audience. This is useful for SaaS products where marketing consent belongs to a particular service or organization rather than globally to an email address.
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. The unsubscribe is also reflected in the Audience Database.
Add an optional 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.
The form does not create or own a separate recipient Database. It writes each response to the Audience Database that was created with the Newsletter. The same managed automations update subscription state and the derived delivery list, so Form submissions, manual changes, CSV imports, and API writes stay consistent.
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 an optional signup form connected to the existing Audience Database; 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_IDCreating a Newsletter through the API also creates its Audience Database and managed subscription automations. A simple automated flow can then add or synchronize recipients, create a Newsletter issue from approved content, 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}/sendSignup form creation is idempotent. The first request creates a Form connected to the Newsletter's existing Audience Database; later requests return the same connected form and automation:
POST /api/v1/newsletters/{newsletterId}/signup-formThe Database API offers another route for integrations that maintain audiences directly. Updating the Audience Database triggers the same subscription automations as manual changes and Form submissions. The Newsletter API remains the convenient interface for Newsletter-specific subscriber operations.
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 Audience Database and Forms that collect recipients, and the people responsible for reviewing the final message.
The result is a compact publishing workflow with one Database-backed audience, explicit subscription state, 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.
Frequently asked questions
What is Newsletters in Aamu.app: from subscribers to sending?
Create Newsletters with a Database-backed audience, manage subscriptions through the UI, Forms, CSV, or API, design reusable templates, and send issues from the same project workspace.
Who is Newsletters in Aamu.app: from subscribers to sending for?
This guide is intended for developers and technical teams.
What does this guide explain?
It explains the Database-backed audience model, optional signup form, templates, sending, and Newsletter API workflow in Aamu.app.