For the complete documentation index, see llms.txt. Every page on this site is also served as Markdown: append `.md` to any URL, or send `Accept: text/markdown`.
Attensira Logo
Attensira

REST API endpoint

GET /v1/automations/{id} — one automation with its latest run inline

The full definition of a single automation together with its most recent run, so did my Monday report run costs one call rather than two.

Karl-Gustav KallasmaaKarl-Gustav Kallasmaa, Founder & CEOLast updated
GET /v1/automations/{id}Needs read scopeSpends no creditsMCP tool: get_automation

The request

Paste this and change the key. Every endpoint takes a bearer key and none takes a workspace id — the key names the workspace.

curl https://api.attensira.com/v1/automations/aut_71cd \
  -H "Authorization: Bearer atn_live_<your key>"

Parameters

Every parameter the published reference documents, and nothing it does not.

NameInTypeDefaultNotes
id*pathstring—The automation id, from the listing endpoint or from the response that created it.

The response (200)

Abbreviated, never invented — this is the shape the published reference documents.

{
  "automation": {
    "id": "aut_71cd",
    "name": "Monday visibility report",
    "trigger": "weekly",
    "status": "active"
  },
  "latest_run": { "id": "ses_9d02", "status": "complete" }
}

What goes wrong, and what it means

The condition on the left, the correct reading of it on the right.

latest_run is null
The automation has never run. That is normal for a manual or once trigger and worth investigating on a daily or weekly one.
latest_run status is running long after the schedule
The run has not finished. Follow its id to the sessions endpoint, where the event trace shows what it is doing rather than guessing from the automation record.
The definition looks right and no runs exist
Check status on the automation itself. A paused automation keeps its schedule and never fires, which reads identically to a broken schedule from this response alone.

What this endpoint cannot tell you

The limits are part of the answer, not a disclaimer under it.

  • It cannot show the run's answer. latest_run is a handle — an id and a status — so the actual output has to be fetched from the sessions endpoint, which is also the only place the step-by-step trace lives.
  • It cannot show run history. Only the most recent run is inlined, so a question about whether the report has been failing for three weeks is not answerable from this response.

There is one question people ask about a scheduled job far more often than any other, and it is not what the job does. It is whether it ran. This endpoint is shaped around that question.

Two things in one response

The response carries the automation itself — the same object the listing endpoint returns, with its instruction, trigger, status and schedule — and, alongside it, the most recent run as a compact handle: an id and a status.

That inlining is the whole design. Without it, checking whether Monday's report happened would mean fetching the automation, then querying for its runs, then reading the newest. With it, the common case is one request, and the answer is visible without parsing anything clever.

Reading the latest run

The run's status is the immediate answer. A complete run happened and produced something. A running one has not finished. A failed one ended without an answer.

A null latest_run means the automation has never run at all. On a manual or once trigger that is the ordinary resting state and says nothing is wrong. On a daily or weekly one it is worth a look: the usual explanation is that the automation was created after the most recent slot, and the second most usual is that its status is paused.

Which brings up the field to check before concluding anything: an automation that is paused keeps its schedule, keeps its definition, and never fires. From a distance that is indistinguishable from a broken scheduler, and this response contains the answer.

Following the run

What you do not get here is the answer itself, and that is deliberate. A run is a session: a sequence of tool calls with arguments, and an answer at the end. Inlining that would make this endpoint enormous and would duplicate the sessions endpoint, which already does the job properly.

So take the id and fetch the session. Ask for the event trace while you are there — it shows which tools the agent called and with what arguments, which is the only way to find out why an answer is wrong rather than merely that it is. An automation whose output has quietly drifted usually turns out to be reading a different slice than its author intended, and the trace is where that becomes visible.

What this endpoint will not do

It carries one run, not a history. A question like "has the Monday report failed three weeks in a row" cannot be answered from this response, and the honest thing is to say so rather than to infer a pattern from a single data point. If you need that, record the run id and status each time you check, and keep the series yourself.

An operational pattern that works

For a small number of automations that matter, a cheap monitoring loop is: fetch each automation, look at the latest run's status and the automation's own status, and raise an alert when a weekly job's newest run is older than eight days or when its status has quietly become paused. All of it is read-only and none of it spends credits, so the loop costs nothing but requests.

Its twin on the other surface

The get_automation MCP tool takes the same id and returns the same pair. It is the natural follow-up to the listing tool in a conversation, which is why both are read-only and neither needs anything beyond read access.

Why the response is shaped this way

It would have been easy to make this endpoint return only the definition and leave runs to a separate collection. The reason it does not is that the question people actually arrive with is almost never "what does this automation say" — it is "did the thing happen". Optimising the response for the second question rather than the first is a small design decision that removes a request from the most common interaction anybody has with a scheduled job, and it is why the run comes back as a compact handle rather than as an entire session.

Questions people ask

Why does the response nest the automation under a key?
Because it carries two things — the definition and the latest run — and keeping them separate means the automation object is identical in shape to a row from the listing endpoint.
How do I read what the last run actually said?
Take the id from latest_run and fetch it from the sessions endpoint. Add the events include there for the step-by-step trace of what the agent did.
What does a null latest_run mean?
The automation has never run. For a manual or once trigger that is the expected state until somebody triggers it.
Can I see the previous five runs?
Not from here. Only the most recent is inlined, by design — this endpoint is built for the did-it-run question rather than for history.
Does this cost credits?
No. Reading an automation is free. Running one spends credits, and that is a different call.

Sources

Every factual statement above, with the page it came from and the date that page was read.

  1. The Attensira API reference states that the single-automation endpoint returns the most recent run inline, so that asking whether a scheduled report ran costs one call rather than two.

    docs.attensira.com · retrieved

    “One automation in full, with its most recent run inline — so "did my Monday report run?" costs one call, not two.”

  2. The API reference states that latest_run is null when the automation has never run, and that its id is passed to the sessions endpoint for the full trace.

    docs.attensira.com · retrieved

    “latest_run is null when the automation has never run. Pass its id to GET /v1/sessions/{id} for the full trace.”

Next

The reference this is written from →Every endpoint →The same capability over MCP →