The automation object

An automation is a workflow that runs when an event fires: a graph of steps a contact moves through, from a trigger to whatever follows it.

Fields

The object returned by GET /v1/automations/{id}, and by create, update and list.

Field	Type	Description
object	string	Always "automation".
id	string	Automation identifier — an opaque, prefixed string, auto_…. Stable for the life of the automation, and the value you pass as a cursor when paginating.
name	string	Your name for it, not shown to contacts.
status	string	enabled or disabled. A disabled automation does not fire — see below.
created_at	string	ISO 8601 timestamp of when the automation was created.
updated_at	string	ISO 8601 timestamp of the last change to it.
steps	array	The nodes of the graph. Only on Retrieve — omitted from list rows.
connections	array	The edges of the graph. Only on Retrieve — omitted from list rows.

A delete returns a stub rather than the object — { object, id, deleted: true }. See Delete an automation.

steps and connections are the graph

Together they describe one directed graph. Retrieve an automation returns them; List automations leaves them out, because a page of full graphs is far more than a listing needs.

A step is { key, type, config }. The key is a string unique within the automation, and it's what connections point at. The type decides what config holds:

type	config
trigger	event_name — the event that starts a run. Exactly one per automation.
send_email	template ({ id }), from, subject, optional reply_to.
delay	duration, e.g. "2 days".
wait_for_event	event_name, optional timeout.
condition	branch config; outgoing connections carry non-default type labels.
add_to_segment	segment_id.
update_contact	the fields to set on the contact.

A connection is { from, to, type }, where from and to are step keys and type defaults to "default" — a plain step has one default-typed outgoing edge, while a condition uses other type labels to mark its branches.

"steps": [
  { "key": "start", "type": "trigger", "config": { "event_name": "user.created" } },
  {
    "key": "welcome",
    "type": "send_email",
    "config": {
      "template": { "id": "d3f8c2a1-6b47-4e9a-b25c-1f0e7a9d4c83" },
      "from": "Ada <ada@acme.com>",
      "subject": "Welcome to Acme"
    }
  }
],
"connections": [
  { "from": "start", "to": "welcome", "type": "default" }
]

status and the frozen graph

status is disabled until you turn it on, and a disabled automation does not fire. Enabling requires a complete graph — one trigger, at least one step after it, every config filled in.

While enabled, the graph is frozen: steps/connections can't be edited because runs may be part-way through them. name and status themselves stay editable. To change the graph, disable, edit, re-enable; to pull it out of service quickly, stop it.

Ids are opaque

auto_… is a prefixed string and nothing more — don't parse it or assume it sorts. A run of this automation carries a run_… id on the same principle. This API is Resend-inspired but not identical, and its ids are its own.