Attribution, funnel alarms and lifecycle email, configured by your agent.
Your product emits business facts — user_signed_up, payment_succeeded, a click on the pricing page. Emit attributes each one to the campaign that caused it, watches every conversion rate for a drop, and acts: welcome, nudge, win back — on your own Postmark, SES or SMTP.
# one call, durable accept — Emit owns everything after the 202 curl -X POST https://api.useemit.com/v1/events \ -H "Authorization: Bearer $EMIT_INGEST_KEY" \ -d '{ "eventType": "user_signed_up", "email": "amina@example.com", "userId": "usr_8f2c1", "idempotencyKey": "acme_signup_usr_8f2c1", "attribution": { "source": "google", "campaign": "ma_launch" }, "properties": { "first_name": "Amina", "locale": "fr" } }' → 202 {"ok":true,"state":"accepted"} attributed to google / ma_launch · counted in this week's signup→activation rate welcome sent · onboarding enrolled · row in the repository · agency notified
A growth engine is a loop: measure what users do, attribute it to where they came from, act on it, feed the result back into acquisition. Email is one actuator in that loop, not the product. There is no "send email" API — there are only events, and what they cause.
One POST per business fact from your backend — signup, activation, upgrade, payment, churn — plus visits and clicks from your site. Idempotent, durable, and a 202 means Emit has it.
First touch frozen at signup, last touch refreshed, click ids kept. Revenue by campaign, CAC once you type spend. Every conversion rate is compared week against baseline, and a significant shift is an alarm, not a chart you had to open.
Mappings, sequences and broadcasts react to the same events — consent-gated, on your own provider. Every event lands pseudonymised in the analytics repository and, allow-listed and signed, at your agency or ad platform.
Topics, templates, mappings, sequences and the event vocabulary are plain configuration on one API. The console and your agent read and write the same documents, so a person and a machine configuring the same project can never drift — and the agent can read the funnel and the trace, not just write config.
Emitconfig scope writes templates, topics, tags, mappings, sequences and broadcast drafts — reversible, and no mail leaves.› Set up Emit for acme_app: a product_updates topic, a welcome template, and map user_signed_up to it. ● Registering topic product_updates … PUT /api/v1/p/acme_app/topics/product_updates → 200 ● Writing template welcome (subject + Markdown, {{first_name|there}}) … 200 v1 ● Preview render with sample values … subject "Welcome to Acme, Amina" ● Mapping user_signed_up → send welcome as marketing on product_updates … 200 Done. The next user_signed_up with a subscribed contact sends the welcome. Nothing was sent: this key can configure, not act. Test-send it from the console.
Run one product or ten. Every feature is per project: contacts, consent, templates, keys and sending identity never leak across.
First touch frozen at signup, last touch refreshed, click ids kept. Revenue by campaign, email influence per conversion, CAC the moment you type spend into the row.
Activation, upgrade, delivery and complaint rates, last 7 days against the prior 28. A significant shift emails you the morning it happens. Value bands and sudden-drop detection on every metric are next.
Resets and receipts skip consent and suppression; promotional mail never does. The class is a field on the mapping, live on the next event.
Multi-step onboarding and win-back, each step with its own topic and condition. An upgrade event cancels the nudge before it races its own send.
Tags, locale, engagement windows, "not already in my other product". Count first, confirm second, pace per hour, pause any time.
Per-topic consent recorded as events. RFC 8058 one-click unsubscribe injected into every marketing email. Double opt-in capture forms with one POST.
Every event, pseudonymised and PII-stripped, in an analytics repository you read through the console, the API and signed destinations. Allow-listed conversions pushed HMAC-signed to your agency or ad-platform bridge, with retries and replay.
Postmark, Amazon SES or SMTP, per class. Credentials envelope-encrypted under your account's key. No pooled sending, ever — and honest about what each provider can report.
One trace call answers it in plain language: which mappings matched, what sent or skipped and why, who was enrolled, what left for the repository.
Every project on one screen, then each project's dashboard: health, setup, volume, funnel, revenue, recent mail and events. Every config action an agent can do, a person can too.
Is anything broken? Is the project set up? Where does the funnel move, and is any of it turning into money? One dashboard per project answers those in order, and the portfolio view puts every project side by side.
Email mistakes are asymmetric: an unsent newsletter is a shrug, a mailed unsubscriber is a complaint. Emit's rules are built on that asymmetry.
No subscribed membership, no marketing mail — silently skipped, recorded with the reason. A misspelt topic is refused at save, not discovered in a report.
Revocations, unsubscribes and account deletions always land. A validation rule is never the reason an opt-out fails.
Complaints above 0.3% of today's sends pause that project's marketing — and only that project's. Transactional mail keeps going. A kill switch does the same by hand.
The first time a mapping sends without consent, the account owner gets an email saying so. Your provider enforces domain verification and complaint rates with teeth Emit does not have.
Storage, sends, enrollments, repository rows, destination deliveries — one key dedupes them all. Retry freely.
Raw addresses never reach the repository or a destination; secret-shaped and person-shaped keys are dropped at any depth. GDPR erasure is a dry run, then a typed confirmation.
No. Emit is a growth engine: it measures what users do, attributes it to where they came from, watches the rates, and acts. Email is the first actuator because it is the one with consent rules and reputation risk that most people get wrong — and a welcome, a nudge and a win-back are what most of the loop's actions look like today. Ads feedback is next.
No, and that is the point. You emit business facts; mappings decide what they cause. It keeps your product free of email logic and keeps every send explainable — the trace tells you exactly why a message went or did not.
Never. Each project sends with the credentials you store — a Postmark server token, SES keys or an SMTP password — encrypted under your account's key and never displayed again. Your domain, your reputation, your provider's dashboards.
Read its project, and with the config scope write templates, topics, tags, mappings, sequences and broadcast drafts. No key can test-send, schedule a broadcast, grant consent, erase a contact or open the breaker. Those need a signed-in person in the console.
A mapping declares its class and it applies on the next event. The first time it sends transactional, the account owner is emailed. Sending promotional mail without consent is what gets a domain suspended by your provider — Emit tells you before that happens, and a platform block can force an abused event type back to marketing.
Contacts, consent and messages live in Emit. Every event is also published, pseudonymised, to an analytics repository behind the funnel, revenue and attribution readouts, and optionally pushed, signed, to HTTPS destinations you allow-list per event type. Raw addresses never leave.
Yes. Accounts hold projects, members and encrypted credentials. Every document is keyed by account, every query is filtered by it, and switching accounts reloads the console so nothing of one stays on screen for another.