POST https://api.usecommune.com/automations/{automation}/activate Production. There is no separate sandbox host.

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.

Path parameters

  • string(uuid) Required

Request Headers

  • string Required
  • string
POST /automations/{automation}/activate
Loading...

Share your request

Use this link to easily share a pre-filled request of this operation. Everything you filled will be shared apart from the authentication fields.

Request URL

https://api-reference.usecommune.dev/explorer/operation/operation-activateautomation

Send a delete request

It looks like you’re about to send a DELETE request to this API. This type of request carries a risk of permanent and irreversible data loss.

Are you sure you want to continue?
Response
Waiting for a request to be sent.