Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteenOne function is the only place a recipient row is ever built, and it checks suppression before writing and again the instant a message would render. Sending demands the recipient count back from you, recomputed at the moment you click — a number that went stale since you looked refuses the send.
What it does
Every card's status label is derived from the backend's own capability module.
HTML sanitised on write, a real audience count, the approval gate and a confirmed send all run and produce the final rendered message. No scheduled-send route exists — a timer cannot supply the human confirmation the boundary requires. Delivery needs a provider.
Needs a keyMerge-on-import, and a written consent basis stored verbatim on every row an import creates. Manual merge of two subscriber rows is not built.
Works todayOne function is the only place a recipient row is ever constructed, and it checks the suppression list before writing — then the whole check runs again, moments later, at the instant a message would render. A suppression is never deleted, only released, and a spam complaint can never be released at all.
Works todayUnauthenticated and idempotent, writing a suppression entry. The renderer attaches List-Unsubscribe headers and a visible footer to every marketing message — the headers only reach an inbox once a provider sends it.
Needs a keyConsent is a separate endpoint from subscriber creation, so the two can never be one write. Capture, evidence, the append-only event log and a confirm endpoint all work locally, and a reminder job now follows up exactly once on an unconfirmed request older than 24 hours. Delivery of both the original email and the reminder needs a provider.
Needs a keySubmitter and approver both recorded; editing the copy after approval clears it. Every resubmission now writes its own approval row, so the full multi-round history is real, and a reminder nudge posts an in-app notification to the named approver — deliberately without needing an email address, so this stays available on its own.
Works todayMerge fields with fallbacks, per-subscriber preview, and a count of how many real recipients a field would render empty for. Conditional content blocks are real now too: a block's condition and its own token in the body, with a required default so it can never render as a hole — resolved per recipient inside the actual send path, not only in preview.
Works todayQueued, blocked-by-suppression and blocked-for-consent counts are real, from the send recipient rows themselves. Opens, clicks, bounces and complaints report as unknown, never as zero, because they arrive on a provider feed nobody has connected.
Built, with limitsYour sending domain is a real record with its own SPF, DKIM and DMARC state, and the records to publish are generated from the domain rather than looked up — so that half is right with no resolver at all. A send is refused only on positive evidence a record is missing; "unknown" never blocks. Reading DNS back, and real bounce and complaint rates, both still need pieces this deployment has not got.
Built, with limitsA closed purpose list, its own rate policy, and the same suppression gate — a bounce, complaint or manual block stops it absolutely. Needs a provider and a separate sending identity.
Needs a keyLekha's regulated-claim guard runs over it, a named human must clear it, and any later edit re-arms the hold. Generating and rewriting now call a real model with a prompt that forbids invented prices, guarantees or regulated claims, and every call is logged for audit. Needs a model key — without one, both routes refuse rather than returning a stub.
Needs a keyAn AND/OR condition tree over tags, attributes, status and consent state, evaluated live by both the preview count and a campaign's own audience — so the two can never disagree. Fails closed on an empty condition rather than matching everyone. Engagement-history conditions aren't offered, since no open-tracking data exists here to build them from honestly.
Works todayWait, send, branch and tag steps, with suppression and consent re-checked before every single step, not only at enrollment — a contact who no longer qualifies exits immediately. Activating an automation is the one explicit human action that authorises its future sends, the same shape Wavy's own abandoned-cart recovery already uses. Delivery needs an email provider.
Needs a keyInstantiating the template creates a real, tenant-owned draft automation you still have to review and activate yourself — a raw CSV import can never trigger it, hard-refused regardless of configuration. Shares the automation engine's send path, so it needs the same email provider.
Needs a keyA per-trigger webhook credential, issued once and stored only as a digest, and the event log both work locally. An abandoned event only enrols a subscriber who already gave marketing consent — an abandoned cart is evidence of a purchase attempt, not consent. Needs a connected e-commerce or booking platform to call the webhook, and an email provider for delivery.
Needs a keyLaunching a test sends real mail to a confirmed sample of the freshly computed audience, through the same approval and confirm-the-count gates a full send requires. Declaring a winner is always a named human action — there is deliberately no auto-select. The remaining-list send still needs its own fresh approval and confirmation, and automatically excludes everyone the test already reached.
Works todayThe unauthenticated submit endpoint records real marketing consent with the form's own name as evidence, applies a target tag, and can enrol into a linked welcome automation. A database-backed rate limit per IP and per form guards against a scripted flood. No delivery is involved anywhere in this path, so it works independent of the email provider every send-shaped capability here is waiting on.
Works todayThe configuration is real — enable per campaign, a stored fallback hour. What the name promises — each subscriber's email arriving at their own best time — needs open-event history from a provider webhook feed this deployment has never had wired, so the engagement profile honestly returns an empty history rather than a guess. A staggered sender built against one fallback hour for everyone would just be a delay wearing this feature's name, so it stays unbuilt.
Built, with limitsWhat a metrics panel actually shows
No worked example on this page shows an open rate. Here is why: opens, clicks, bounces and complaints arrive on a provider webhook feed, and until one is connected, unknown is the honest answer.
| Metric | Shown as | Why |
|---|---|---|
| Queued | A real count | Counted directly from this campaign's own EmailSendRecipient rows. |
| Blocked — suppressed | A real count | Counted the same way, from the same rows. |
| Blocked — no consent | A real count | Counted the same way, from the same rows. |
| Opens | Unknown, not zero | Arrives on a provider webhook feed nobody has connected. Even connected, an open count is partly a count of Apple Mail Privacy Protection pre-fetching the tracking pixel. |
| Clicks | Unknown, not zero | Same provider-feed gap as opens. |
| Bounces | Unknown, not zero | Same provider-feed gap. A zero and an unknown look identical on a dashboard and mean opposite things. |
| Complaints | Unknown, not zero | Same provider-feed gap. Reporting zero would read as "nobody complained" when the true state is "nobody is watching". |
How it looks
Limits
Every figure here is a constant in the codebase.
| Marketing stream — daily cap | 500 messages/day |
|---|---|
| Marketing stream — pacing between sends | 0.5–2.0 seconds |
| Transactional stream — daily cap | 5,000 messages/day |
| Subscriber list — default page size | 200 rows |
| Suppression list — default page size | 500 rows |
What it refuses to do
Before you switch
Tell us the size of your list today and we will show you exactly what Patri carries — and the six things it still hands back to you.
Questions
Unknown, not zero — and this page will not show you one either. Opens, clicks, bounces and complaints all arrive on a provider webhook feed, and until one is connected the honest answer is "we don't know", not a made-up zero. Even connected, an open count is partly a count of Apple's Mail Privacy Protection pre-fetching the tracking pixel, so it would be shown as a directional signal, not a fact.
Sending demands the recipient count back from you, recomputed at the moment you click. If the list changed since you looked — someone unsubscribed, a tag was edited — the number you hold is stale, it will not match, and the send is refused. This is deliberate: the specification's own top risk is an accidental send to an entire contact table, and a confirmation that could go stale between preview and click would not actually confirm anything.
Only if it was never a spam complaint, and only after a fresh consent record dated after the suppression exists. The suppression entry itself is never deleted — it is released, keeping the history that justified the release in the first place. There is no DELETE route for this at all.
Through exactly one function, everywhere in the codebase. It checks suppression and consent before writing a single row, blocked addresses get a row explaining why rather than being silently dropped, and the whole check runs a second time — not a cheaper copy of it — the instant a message would actually render.
No. Copy the assistant drafted is always held, run past a regulated-claim guard, and needs a named human to clear it. Edit the copy after it's cleared and the hold comes back — an approval cannot survive a change to the wording it covered.
Nothing, in the sense of missing code — all eighteen specified capabilities have a real implementation. Four of them (automated workflows, a welcome series, abandoned-action recovery and the AI copy assistant) need a credential this deployment hasn't supplied — an email provider or a model key. One, send-time optimisation, stays honestly partial: it needs open-event history from a provider webhook feed, a second system this deployment has never had wired, not only a key.
