March 2026

Audience: Contacts, Lists, Segments And Topics

Lettr gained a place to keep the people you send to, rather than treating a recipient as an address that exists only inside one request.

It is built from four ideas. Contacts are people: an email address, a status, and any number of properties your team defines. Properties are typed and each carries an optional fallback, so a merge tag that lands on someone who never filled the field in still renders something.

Lists are deliberate groupings, filled by hand, by import or over the API. Segments store a condition instead of a membership and are evaluated when read, so a segment for contacts in Germany who opened something last month describes different people next week without anyone touching its definition. Sixteen operators are offered, narrowed to what each field type can actually do, and a segment can be scoped to a single list. There is a natural-language route too: describe the audience you want in a sentence and it is turned into a condition tree you can then edit.

Topics record what someone agreed to receive. Dropping one topic leaves the others intact, which is the whole argument for topics over a single global unsubscribe that throws away information you cannot get back.

Importing is a three-step flow — upload, map your columns, then a queued job that works through the file in chunks and emails you when it is done. Two assists sit in the middle of it: one decides whether your first row is a header row and invents headers when it is not, the other proposes which column belongs to which property. On a re-import you choose the duplicate strategy explicitly, skipping existing contacts or merging the row's properties into them. Either way an import never duplicates somebody: rows are matched on a lowercased email. Rows with a missing or invalid address are counted and reported rather than failing the file.

Contacts created over the API can go through double opt-in — Lettr sends a confirmation email from a template you name, and a public confirm endpoint marks the contact and redirects wherever you say.

Marketing Billing Is A Separate Line

Audience bills on its own meter, priced on how many contacts you keep, entirely separate from the email-volume tier you already pay for.

Adding an audience therefore does not change what your existing plan costs. The first 500 contacts are included at no charge on every subscription. Moving down a tier is refused while you still hold more contacts than the smaller tier allows, rather than silently dropping people.

Alerts When Your API Error Rate Climbs

A new Alerts page watches the failure rate of your API calls and tells you when it goes up.

Two checks run: a fifteen-minute one for sudden breakage and a daily one for the slow kind. Crossing your threshold notifies the team owner, subject to a cooldown you set, a minimum request volume so one failed call on a quiet account cannot alert, and a rule that suppresses the daily alert when the fifteen-minute one has already fired.

Alerts arrive by email, by webhook, or both. A webhook target has to be a genuinely public URL, there is a test-send button, and every delivery is signed with a per-team secret you can regenerate.

Restrict An API Key To Specific Sending Domains

A key can now carry an allow-list of sending domains, and a send whose from domain is not on it is rejected instead of going out.

A key with an empty list stays unrestricted, so nothing changes for keys you already issued. It makes a leaked key considerably less useful to whoever leaked it.

Custom Headers On A Send

POST /api/emails accepts a headers object — up to ten of them, each value at most 998 characters.

Headers that decide where a message goes or how it is signed are refused by name, From, To, Reply-To, Subject, Date, Message-ID and DKIM-Signature among them, as are List-Unsubscribe and List-Unsubscribe-Post, because Lettr manages those itself.

curl -X POST https://app.lettr.com/api/emails \
  -H "Authorization: Bearer $LETTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "billing@example.com",
    "to": ["jane@example.com"],
    "template_slug": "invoice",
    "headers": {
      "X-Mailer": "acme-billing/2.1",
      "X-Entity-Ref-ID": "inv_88213"
    }
  }'