Turn an automation on
Makes an automation live. Needs sending: write, and is a write.
This is the operation that starts sending. Everything else about an automation describes a sequence; this installs it. From the moment it returns, Commune mails whoever the trigger names, as often as it fires, with no further request from anybody, until a person turns it off.
Every gate runs again, on the stored automation. They ran when the
graph was saved, and the repetition is deliberate: an automation can be
saved by one tool and turned on by another weeks later, and in between
an image can rot, a tag a step applies can be deleted, and a sending
domain can fall out of verification. Each is a 422 naming what is
wrong:
- the graph, if an edge points at nothing, a path does not end, or there is a cycle;
- a condition, if it uses a keyword outside the subset or names a path its trigger cannot produce;
missing_footer, if an email has lost its unsubscribe link or its mailing address;broken_images, if an image in an email definitively will not load. There is no way to override this one here, unlike on an article send: an article's images are checked minutes before it goes out, and an automation's are checked once and then sent for months;- the newsletter, if Commune does not send its email, or it has no verified sending address. These apply only when the graph actually sends: an automation that only moves tags works on any newsletter.
It is charged to a daily cap of its own, counted per newsletter and
reported as a 429 that is not one of the RateLimit-Policy budgets. An
activation is not a send: it installs a standing instruction. The number
is also how many copies of one email a single subscriber could be made
to receive from one triggering event, because each automation claims its
deliveries separately. An activation that was refused costs nothing, so
fixing a graph and trying again is free until it succeeds.
How many may run at once is a plan limit, and the only 402 this
operation can answer: a newsletter whose plan does not include it may
have one automation active, and this is refused while another is
running, naming how many are running and how many are allowed. Pausing
one makes the same call succeed. Creating, editing, reading and
archiving are not limited, so building and comparing several sequences
needs no plan; only running a second one does.
Turning on an automation that is already active succeeds and changes
nothing. An archived one is refused: archiving ended its runs.
Publishes no event.
Loading...
Waiting for a request to be sent.