Email automations driven by your product's events
A workflow that runs per contact. Something happens in your product, the person is enrolled at the trigger, and the graph carries them through sends, delays and branches until it runs out.
What an automation is made of
A workflow is a small directed graph: one trigger, a handful of steps, and the edges between them. It is written once as data, so the editor and the API describe the same thing.
Triggers your product fires
Declare an event name once, then fire it against a contact from your own code. Every enabled automation whose trigger names that event enrolls the contact. Built-in triggers cover what Rasket already knows: a contact created, a topic subscribed, a segment entered.
Six kinds of step past the trigger
Send a published template, delay for a duration or until a date, branch on a rule about the contact, update their properties, add them to a segment, or change one topic subscription. At most 150 steps, exactly one trigger, no cycles.
Versions, so nobody is rewritten mid-flight
An automation is an identity plus immutable versions of its graph. Publishing a change writes the next version and points the automation at it. A run already under way keeps the version it started on, and every past version stays readable.
Every run is a record you can open
A run is one contact's journey. It lists each step in graph order with its status, when it started, when it finished and what it produced, including the id of the email a send step created. Runs also raise their own events, so your endpoint hears when one starts, completes or fails.
The whole graph is checked before it publishes
Every template, segment, topic, property and event name a graph uses has to resolve against your own team. A failure comes back with one message per step, so an editor can put each problem on the node it belongs to.
How a workflow goes from an event to a run
Three moves from nothing to a workflow that is running, and none of them needs a deploy on our side.
- 1
Declare the event
Name it once, with an optional schema for the payload it carries. A key restricted to sending can fire it, so the service that knows a trial started does not also need a key that can read your contacts.
- 2
Publish the graph
Steps and connections, validated as a whole. An automation starts disabled, so nothing enrolls until you enable it, and enabling changes only who is enrolled next, never a run already going.
- 3
Fire the event and watch the runs
One run per contact per enrolling event. A run parked on a delay still reports as running, because a delay is a moment it wakes at rather than a process holding a thread, so a restart loses nothing.
Start a workflow from your own code
This is the only call your application has to make. The workflow itself lives in Rasket, so changing what happens after a trial starts is not a change to your code.
Fire a custom event
curl https://api.rasket.com/events/send \ -H "Authorization: Bearer rk_..." \ -H "Content-Type: application/json" \ -d '{ "event": "trial.started", "email": "ronald.williams@example.com", "payload": { "plan": "pro" } }'
HTTP/1.1 202 Accepted{ "object": "event", "event": "trial.started" }The answer is 202, not 200: the event is durable the moment the call returns, and the runs it enrolls start on the next tick. There is no idempotency key here, because two calls are two events and two runs. The custom events reference covers names, schemas and payloads, and the automations reference covers the graph language in full.
What a run is, and what it costs
A run is one contact moving through one version of one graph. It is created the moment the enrolling event is durable, and the same event can never create the same run twice, however many times it is redelivered inside our own system. Two sends of the same event are two runs, because that is what you asked for; one send redelivered internally is still one.
Runs are where the work is, so runs are what is counted. Each plan includes an allowance each month, and past it a run is charged as usage if pay-as-you-go is on and refused if it is not, with the reason written onto the run so you can see it rather than guess. Runs and their steps are kept for ninety days on every plan. The pricing page has the current allowance for each plan.
Automations lean on the rest of the product rather than reimplementing it. A send step uses a published template, so the content is versioned the same way the graph is. The contacts, segments and topics a workflow reads and writes are the same ones broadcasts go out to. And a run raises events like anything else, so the signed webhooks you already receive tell you when one starts, finishes or fails.
Questions about automations
What can start an automation?
A custom event you declare and fire from your own product, or one of the built-in triggers Rasket already raises, such as a contact being created, a topic being subscribed to or a segment being entered. One event send enrolls that contact into every enabled automation whose trigger names it.
What can a step do?
Send a published template, delay for a duration or until a date, branch on a rule about the contact, update the contact's fields or properties, add them to a segment, or opt them in or out of one topic. Two step types in the schema, waiting for an event and deleting a contact, are not available in this release, and a graph naming either is refused rather than quietly ignored.
What happens to runs in flight when I change a workflow?
Nothing happens to them. Publishing writes a new version and points the automation at it, and each run keeps the version it started on. Disabling an automation stops new enrolments and leaves live runs alone; stopping it cancels those too.
Do the emails an automation sends behave like ordinary sends?
Yes. A send step goes through the same transaction as a single send does, so your quota, suppressions, unsubscribe headers and delivery events all apply unchanged, and the email shows up in your logs beside everything else.
Can I see what happened to one person?
Yes. Every run is one contact's journey and lists its steps in graph order with their status, timings, output and any error. A send step records the id of the email it created, so you can follow it into that message's delivery timeline.
How are automation runs counted?
Each plan includes a number of runs a month, and the free plan includes ten thousand. Past the allowance a run is charged as usage if you have turned pay-as-you-go on, and refused if you have not, with the reason recorded on the run itself. Runs are kept for ninety days on every plan. See the pricing page for the current figures.
Build your first workflow
Declare one event, draw a graph of three steps, and let the next person who signs up walk through it.