Short answer: Create newsletters, manage subscribers, design reusable templates, send test messages, publish issues, and automate the workflow through the Aamu API.
Newsletters in Aamu.app bring the audience, email design, individual issues, scheduling, delivery reports, and automation into the same project workspace. A team can prepare an update alongside the Docs, Tasks, Forms, and Database rows that supply its content and recipients.
The workflow starts with a Database-backed audience and ends with an explicit sending decision. Between those steps, editors can personalize the message, review the eligible recipients, send a test, and choose when the campaign should begin.
Aamu implementation update, 16 October 2026: desktop and mobile previews, subscriber history and acquisition reporting are implemented in the latest version. These additions appear in a workspace once that version is deployed.
Find your way around a Newsletter
A Newsletter has six practical areas: Issues, Subscribers, Template, Signup form, Database, and Settings. The Database holds the audience data, Subscribers provides the subscription view, and Template defines the reusable email design. Newsletter Settings contains the sending mailbox, sender name, Reply-To address, confirmation options, batch settings, and public archive settings.
Each issue opens as its own page under Issues, with three tabs:
Report: campaign progress, delivery feedback, clicks, unsubscribes and sending problems.
Content: the subject, inbox preview text, message editor, desktop/mobile and subscriber previews, HTML-size feedback, and test sending.
Settings: personalization fields, the campaign audience, scheduling, the pre-send review, sending controls, and publication of a public archive copy.
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. A signup form is optional: you can start adding recipients immediately.
Contacts can enter through the UI, CSV import, an Aamu Form, the Newsletter API, or direct Database updates. These routes converge on the same audience. The Subscribers view is a derived delivery list, so integrations do not need to maintain a second independent recipient list.
Subscription records retain the source and time of joining. A Newsletter can require double opt-in: a contact remains unconfirmed until the recipient follows the confirmation link. Only eligible active subscribers enter a production campaign; unsubscribed, unconfirmed, and blocked addresses are excluded as appropriate.
The Subscribers view supports search, status filters, and paging. Opening a subscriber shows a dialog for reviewing subscription and delivery information and editing the name or address. A permanent recipient failure can block future attempts. Where bounce re-verification is available, the recipient must confirm the address before the block is released; simply running the campaign again does not retry a known invalid address.
Read the subscriber's history
The subscriber dialog includes a paginated timeline of available subscription and consent events, campaigns and counted link visits. Campaign names link back to their issues. Retained signup, confirmation and unsubscribe timestamps are labelled as current records. Aamu does not reconstruct older events that were never recorded.
Campaign entries show the latest recorded delivery outcome. Automated and repeat visits remain separate from counted clicks, and older visits without bot classification are identified. This history provides context for the relationship with a reader; it does not prove that every counted visit was human or that SMTP acceptance meant inbox delivery.
Collect subscriptions with an optional Aamu Form
The Signup form tab creates a public, editable Form connected to the existing Audience Database. It begins with email and name fields and remains a normal Aamu Form, with editable fields, theme, public URL, and thank-you page.
Form submissions use the same subscription automations as other audience changes. Repeated submissions update the matching subscription instead of creating duplicate delivery entries. The form does not create a separate mailing list.
Ordinary unsubscribe links open a confirmation page and update the audience when confirmed. Messages also include one-click unsubscribe headers for compatible email services. A recipient's subscription choice belongs to the relevant Newsletter; it does not automatically unsubscribe the address from every unrelated audience.
See where subscribers came from
Newsletter signup forms capture UTM source, medium, campaign, content and term, together with the form ID, landing page and referrer. This visitor-reported acquisition information is separate from the existing insertion source, such as an import or API addition. Later edits to subscriber details preserve the captured first signup attribution. Older contacts without captured information remain unattributed.
The subscriber dialog shows acquisition details. The Subscribers report groups source, medium, campaign and form, with deduplicated address counts, valid confirmation proof and addresses with classified production campaign clicks. It refreshes with the audience report, approximately every five minutes. Use it to compare the readers produced by different signup campaigns, while treating click-based activity as an imperfect signal.
Reuse the design and write each issue in Content
The content template defines the publication's repeatable structure, including the issue-content area and unsubscribe element. The outer wrapper controls the surrounding email HTML and contains exactly one {{CONTENT}} placeholder. It can also use {{SUBJECT}}. A complete HTML document with html, head, and body is a valid wrapper.
On an issue's Content tab, write the subject and message and add optional Preview text. This is the short summary shown beside the subject in many inboxes; it is hidden in the email body, and its display depends on the recipient's email app.
Open Preview to see the message inside the Newsletter's design, then choose Desktop or Mobile (375 px). Enter an existing subscriber's email to preview their name and referenced Database fields. Leave it empty to check the fallback text. Use Refresh preview after changes to load the latest saved content. This preview does not send an email, alter consent or require a configured sending mailbox; rendering can still differ between email apps.
The Content tab also shows a live HTML-size estimate, including the template, before personalization and tracking links. The warning starts at 85,000 bytes. The final sending review still checks each recipient's tracked HTML against the 100,000-byte limit, so the editor estimate is an early warning rather than a replacement for that check.
Send test sends to the signed-in user when that address is an eligible active subscriber. It uses the real subscriber-specific unsubscribe link. Test deliveries are excluded from production campaign statistics.
Choose the audience and personalization in Issue Settings
In Campaign audience, narrow the list with required tags, alternative tags, and Database field conditions. For example, a product update could target active customers with a particular subscription plan. Every field condition must match, and the final audience still has to pass the subscription and sending-block checks.
The Personalize content section lets you select a subscriber or eligible Database field and supply fallback text. Use Copy field, then paste the placeholder into the message or subject on the Content tab:
Hello {{subscriber.name|friend}},Database placeholders use the selected field's ID. The field picker provides the correct placeholder. Personalization substitutes text; links, HTML attributes, and styles remain fixed. Recipient values are saved when the campaign enters the queue, so later audience edits do not silently rewrite an already queued message.
Review, schedule, and send in growing batches
Review & send checks the sender configuration, unsubscribe link, message size, and eligible audience. The review shows the sender and Reply-To address, recipient count, exclusions, batch plan, and a personalized message example. Confirming the review places the campaign in a persistent background queue.
Sending continues independently of the browser tab. Recipient-specific states record pending, successful, failed, skipped, or uncertain attempts. You can pause a campaign and continue its remaining recipients. If a connection failure leaves an attempt uncertain, Aamu pauses for review rather than automatically sending that message again.
Campaigns always use automatically growing batches. Configure the limits in the Newsletter's Settings:
Initial batch: 1–50 recipients; the default is 50.
Waiting period: 24–168 hours between batches; the default is 24 hours.
Growth factor: 1.1–2; the default is 2.
Sender-domain warmup is shared across campaigns using the same domain. Growth depends on the observed sending results, and recorded delivery problems can hold or pause progress. A larger audience can therefore take several days to send; reaching the start time does not mean the whole list receives the message immediately.
To send later, use Schedule sending in Issue Settings and choose a date, time, and timezone. You can update or cancel the schedule. At dispatch, Aamu uses the latest saved content, sender settings, and eligible audience and runs the sending checks again.
Follow delivery and engagement in Report
The Report tab updates automatically. It separates pending and current sending work from messages accepted by SMTP, failures, uncertain outcomes, skipped recipients, reported bounces, delays, and complaints. It also shows campaign unsubscribes, recipients who clicked, total clicks, link results, recipient-domain breakdowns, and problems grouped by reason.
Accepted by SMTP means the mail server accepted the submission. It does not prove that the message reached an inbox. A later delivery report can still record a failure or delay. Reported recipient failures and complaints can stop future sends, while routing or server problems are classified separately.
Click reporting distinguishes recognized automated visits and rapid repeats from counted engagement. Email scanners and privacy features can still affect the numbers, so use them as campaign signals rather than an exact record of human activity.
Subscriber profiles complement these campaign reports with a reader-level timeline.
Manage the sender in Newsletter Settings
Before sending, connect a mailbox on a verified email domain. You can change the visible sender name and Reply-To address in Newsletter Settings. An empty Reply-To uses the sending mailbox. Queued campaigns retain the sender settings captured when they entered the queue.
Mailbox credentials are shared by Aamu features using the same managed mailbox in the workspace. The connection form checks SMTP and IMAP without sending a message. A workspace administrator can update Aamu's stored password after successful connection checks; this does not reset the password on the mail server.
Mailcow delivery feedback is matched to Aamu's tracked sends, so a newly configured sender does not require a separate per-address feedback switch. Feedback processing is monitored, and repeated delivery or complaint problems can pause sending and alert administration.
Publish a public archive separately from sending
Enable the public archive in Newsletter Settings, then preview and publish an issue's Public archive copy from its Settings tab. Sending an email and publishing a web page are separate actions.
The public copy uses fallback text instead of recipient-specific personalization. Review it for any personal information written directly into the message. Publishing creates a snapshot: later editing does not change the public page until you publish an updated copy. You can also unpublish an issue.
The archive provides shareable issue pages. A custom hostname requires domain ownership verification and the corresponding DNS and hosting setup. Integrations can use the Newsletter API to build their own publication frontend as well.
Automate the same workflow through the API
The project-scoped Newsletter API can manage Newsletters, draft issues, subscribers, audience selection, previews, subscriber history, reviews, scheduling, reporting, and archive publication. Requests use a Team API key with the appropriate Newsletters scope and the project header:
x-api-key: YOUR_API_KEY
x-project-id: YOUR_PROJECT_ID
Content-Type: application/jsonCreate a draft with a subject, HTML, and optional inbox preview text:
POST /api/v1/newsletters/{newsletterId}/issues
{
"subject": "Product update",
"preview_text": "What changed and what is coming next",
"html": "<p>Hello {{subscriber.name|friend}},</p><p>Here is this month's update.</p>"
}Preview and inspect reader history
The read-only preview can use a subscriber's values, or fallback text when subscriber_email is omitted. Subscriber history returns a page of events and an opaque history.nextCursor; pass it as cursor for older entries.
GET /api/v1/newsletters/{newsletterId}/issues/{issueId}/preview?subscriber_email=reader%40example.com
GET /api/v1/newsletters/{newsletterId}/subscribers/{subscriberId}/history
GET /api/v1/newsletters/{newsletterId}/subscribers/{subscriberId}/history?cursor=NEXT_CURSORPreview and subscriber history require Newsletters read permission. Subscriber responses include acquisition, and the audience report includes the acquisition breakdown.
Review and send explicitly
Send a test, then request the production review. Pass its returned review.token when confirming the send:
POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/send-test
POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/review
POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/send
{
"review_token": "TOKEN_FROM_REVIEW"
}The send endpoint returns 202 with queued: true; it does not wait for every recipient to be sent. A changed subject, content, sender, audience, or batch configuration invalidates the supplied review token and requires another review.
Scheduling and cancelling use separate operations:
POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/schedule
POST /api/v1/newsletters/{newsletterId}/issues/{issueId}/cancel-scheduleThe schedule request supplies send_at, timezone, and the review token. The optional signup form is created idempotently with POST /api/v1/newsletters/{newsletterId}/signup-form. Direct Audience Database updates use the same managed subscription automations. Subscriber API responses do not expose private unsubscribe tokens.
For AI and other automations, keep creating or editing a draft separate from permission to send it. A review can prepare the decision; delivery remains an explicit action. See Building with the Aamu API for the wider authentication model and platform workflows.