Preview the campaign. The platform can refuse it.

GET /v1/broadcasts/:id/preview

{ "can_send": false,
  "blocked_reason": "Complaint rate over the
    last 14 days is 0.120%, above our 0.08%
    ceiling. Narrow the segment to engaged
    contacts." }

The same check runs again immediately before the fan-out begins, in the send path rather than on a dashboard. A refused campaign is marked failed with the reason on it.

Mailbox providers and the layer underneath review an account at roughly a 5% bounce rate and a 0.1% complaint rate, and a review pauses every product’s mail, not one campaign. So the gate stops short of both: a 4% bounce ceiling and a 0.08% complaint ceiling, measured over the last 14 days.

Under a thousand sends in the window there is too little history to judge, and the campaign goes through. The alternative to refusing one campaign is having all of them paused, and the only version of that trade that works is the one made automatically.

The sequence, and the enrolment

POST /v1/automations
{
  "name": "Onboarding",
  "slug": "onboarding",
  "identity_id": "idn_news…",
  "from": "Acme <hello@news.acme.com>",
  "trigger": { "kind": "api" },
  "exit_on_reply": true,
  "steps": [
    { "delay_minutes": 0,
      "template_slug": "welcome",
      "subject": "Welcome to Acme" },
    { "delay_minutes": 4320,
      "template_slug": "day-3",
      "subject": "Three things to try" },
    { "delay_minutes": 10080,
      "template_slug": "day-10",
      "subject": "How is it going?" }
  ]
}

POST /v1/automations/:id/enroll
{ "email": "maya@acme.com",
  "variables": { "name": "Maya" } }

201 { "enrolled": true, "enrollment": { … } }

# the same call, retried
200 { "enrolled": false,
      "reason": "already_enrolled" }

“Enrol this person in onboarding” is a better tool call than “schedule three emails and remember to cancel them”. POST /v1/events with a name like trial_started starts every automation waiting on it, so the calling app never has to know which sequences exist.

Three automatic exits

• Unsubscribe. Ends every enrolment for that address, alongside cancelling whatever was already scheduled. Cancelling the scheduled sends alone stops one email and lets the sequence generate the next, which reads to the recipient as an unsubscribe that did not work.
• Reply. With exit_on_reply, an answer from the person ends the sequence. A drip that keeps arriving after someone has replied is the most common way an automation reads as broken. This is only possible because the platform receives mail.
• Hard bounce. A permanent bounce suppresses the address, and the next step finds the suppression and ends the enrolment rather than sending into a mailbox that does not exist.

Enrolling twice is a no-op, guaranteed by a partial unique index rather than a check, so a retried call after a timeout cannot start the sequence twice. Steps are read live from the definition: fixing a typo reaches people already mid-sequence.

Per-person preferences

POST /v1/topics
{ "key": "newsletter", "name": "Newsletter",
  "default_subscribed": true }

POST /v1/topics/preferences
{ "email": "maya@acme.com",
  "topics": { "newsletter": false } }

# a send under that topic
POST /v1/emails
{ "to": "maya@acme.com",
  "topic": "newsletter", … }

202 { "skipped": true,
      "reason": "unsubscribed_from_topic:newsletter" }

Given only all-or-nothing, a person who wants fewer newsletters but still wants their invoices often presses spam instead, and a complaint costs the domain far more than an opt-out. A preference is keyed on the person and the topic, never on a contact row: someone on two lists has one opinion about newsletters. The one-click unsubscribe header is scoped to the topic when there is one.

Templates that refuse to half-render

POST /v1/templates
{ "slug": "welcome",
  "name": "Welcome",
  "subject": "Welcome, {{name}}",
  "html": "<p>Hi {{name}}, you are on {{plan}}.</p>" }

POST /v1/templates/welcome/render
{ "variables": { "name": "<script>alert(1)</script>" } }

422 { "error": {
  "type": "missing_variables",
  "missing": ["plan"] } }

# with both supplied, the value is escaped:
"<p>Hi &lt;script&gt;alert(1)&lt;/script&gt;, …"

Values come from agents and end users. They are HTML-escaped on substitution, so a name like <script> cannot execute in webmail and a prompt-injected value cannot rewrite the message around it. A missing variable is an error, not an email with {{plan}} visible in it. Render without sending to check the copy first.