Say what should happen. It runs, every time.
Event-driven journeys you can read top to bottom: a trigger from your app or your audience, waits, branches, sends, webhooks. Describe one to Unit or draw it. Same templates, same domains, same rules.
- block types
- 19
- from draft to live
- 1 click
- extra sending paths
- 0
Real journeys
One sentence in. A working automation out.
Every graph below is a real blueprint from the product, rendered block for block. The prompt is what you'd say to Unit.
Any trigger, any sequence — these are just the blueprints
“When someone abandons a cart, wait a day. If they still haven't bought, send the reminder with their items.”
AI-native
Built with Unit, approved by you.
Unit reads the same block catalog the engine runs, so it builds from what's real — then validates, and hands you the publish button.
Drafts stay drafts
Nothing goes live until you approve. Publishing, resuming, and cancelling runs all ask first.
Fixes its own mistakes
Validation returns machine-readable codes, block ids, and field paths. Unit repairs and re-checks.
Debugs a run in words
“Why didn't Sam get the offer?” — Unit reads the run ledger and tells you the block and the reason.
- Reads the block catalogevery field, output, and data path — no guessing01
- Drafts the graphfrom a blueprint or from scratch, in your workspace02
- Validates itwiring, cycles, consent, missing data — machine codes it can fix itself03
- Asks you to publishgoing live is always your click04
Fits your stack
Your events in. Your systems out.
One event bus. Your backend emits; automations, webhooks, and Unit all listen. Actions go back out through the API you already use.
POST /v1/events
Bare event names from your code — cart.abandoned, subscription.renewed — with an idempotency key.
Same sending gate
Published templates, verified domains, suppression, quota, tracking, webhooks. No parallel path.
Signed webhooks out
A block can POST the run context to your API, HMAC-signed with a secret only you know.
- POST /v1/eventsyour backend's events
- Contact activitycreated · segment · topic
- Email activityopened · clicked · bounced
- Send emailyour templates & domains
- Call your webhooksigned run context
- Update the contactfields · topics · segments
The blocks
Nineteen blocks, all in plain English.
This list is generated from the catalog the engine runs — what you see here is exactly what you can drop on the canvas or ask Unit for.
- Contact createdStarts when a new contact is added to the workspace.
- Contact updatedStarts when a contact's fields change (optionally only specific fields).
- Joined segmentStarts when a contact enters the segment.
- Left segmentStarts when a contact leaves the segment.
- Subscribed to topicStarts when a contact subscribes to the topic.
- Unsubscribed from topicStarts when a contact unsubscribes from the topic.
- Email activityStarts on email events (opened, clicked, bounced, …), optionally scoped to a campaign or template.
- Custom eventStarts when your backend sends a named event via POST /v1/events (e.g. cart.updated).
- Manual enrollmentStarts only when explicitly enrolled via the UI, API, or Unit AI.
- Send emailRenders a template and sends it to the run's contact (or a fixed address), through the full sending gate.
- Update contactSets or clears contact fields (built-in and custom).
- Change topic subscriptionSubscribes or unsubscribes the contact from a topic.
- Add/remove from segmentAdds or removes the contact from a static segment.
- Call webhookSends a signed POST with the run context to your URL (SSRF-guarded, retried).
- WaitPauses the run for a fixed duration (hours, days, weeks).
- Wait for event2 pathsPauses until a matching event arrives for this contact, or the timeout elapses.
- If / else2 pathsRoutes the run by a condition on contact, event, or step data.
- Multi-branchn pathsRoutes down the first branch whose condition matches, else the fallback.
- Exitends the runEnds the run immediately (with an optional reason).
Safe by construction
Powerful, and hard to hurt yourself with.
Loops, double-sends, and stuck journeys are structural problems. We made them structurally impossible instead of writing warnings about them.
No loops, by construction
Graphs must run forward. An automation's own effects can't re-trigger it, and chains stop after five hops.
Consent decided per email
Marketing honors unsubscribe and topics. Transactional always delivers. You choose, on the block.
A daily cap across journeys
Two automations colliding on one person is normal. Cap marketing sends per contact per day; the extra one skips.
Pause freezes, resume continues
Runs stop exactly where they are and pick up there. Publishing a fix resumes them too.
Versions pin runs
Edit freely — every run finishes on the version it started on. New enrollments take the new one.
Re-entry you control
Once ever, once per interval, or every time — per automation, and it survives run retention.
- completedSam RiveraCart reminder · sent4 steps
- waitingPriya NairWaiting for a purchase · 19h left2 steps
- exitedJon EkPurchased before the reminder2 steps
- skippedAna CostaSkipped — daily send cap reached3 steps
Questions
Common questions
Can I use automations today?
Automations are in early access behind a launch flag: the builder, the run engine, Unit's authoring tools, and a beta API are built and running for early-access workspaces. Join the waitlist from this page and we'll turn it on for you as we widen the rollout. Everything else on the platform is available now: transactional sending, scheduled campaigns, contacts, topics, templates, inbound, and webhooks.
What can start an automation?
Your own backend events (POST /v1/events with a bare name like cart.abandoned), contact lifecycle (created, updated, joins or leaves a segment, subscribes or unsubscribes from a topic), and email activity (opened, clicked, bounced, replied, and more). Each automation has one trigger with an optional enrollment condition.
Will it send through my existing templates and domains?
Yes. A send block renders a published template and goes through the same sending gate as the API and campaigns: verified domain, suppression list, quota, tracking, webhooks. There is no second sending path. You choose per block whether an email is marketing (honors unsubscribe and topics, counts toward the daily cap) or transactional (always delivers).
How does the AI part work?
Ask Unit in the dashboard describes what it's building from the same block catalog the engine runs, drafts the graph in your workspace, validates it (wiring, cycles, consent, missing data), and shows you the result. Going live is always your click — Unit never publishes on its own. When the beta API opens, external agents get the same operations over MCP.
What happens when something goes wrong?
Every run is a ledger: each block records what it did, what it skipped and why, or what failed and where. A deleted template pauses dependent automations before a single run breaks; a broken block can trip a circuit breaker that pauses the automation for review. Pausing freezes runs in place and resuming continues them — nothing is lost mid-journey.
Can I build drips without automations in the meantime?
Yes: call POST /api/v1/email when your app decides someone should hear from you, with scheduled_at up to 90 days ahead, and subscribe a webhook to delivery and engagement events so your own job runner can decide the next step. Automations move that logic into a graph you can see and hand to Unit.
The journeys your customers deserve, without the platform tax.
Early access is rolling out workspace by workspace. Tell us the first journey you'd build — it shapes what ships next.
Join the waitlist