Does creating an automation cost credits?

No. Creation is free. Every run it performs spends credits like a manual run, which is where the ongoing cost sits.

What is the difference between manual and once?

Neither runs on a clock. Manual waits to be triggered and can be triggered repeatedly; once fires a single time and then reports its status as done.

How do I restrict what an automation may do?

Name the tools it may use in the allow-list. Omitting the list allows everything the plan includes, so restriction is an explicit act.

Why does the timezone matter if I set the minute anyway?

Because the minute is minutes past local midnight in that zone. Without a zone the schedule is in UTC and drifts against local time twice a year.

Can I change an automation after creating it?

This endpoint creates. For the current definition read the single-automation endpoint, and for removing one entirely there is a separate destructive call.

REST API endpoint

POST /v1/automations — schedule work in plain language

Defines a new automation that runs an instruction on a trigger. Creating one is free; every run it goes on to perform spends credits.

Karl-Gustav Kallasmaa, Founder & CEOLast updated 4 September 2026

POST /v1/automationsNeeds write scopeSpends no creditsMCP tool: create_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 -X POST https://api.attensira.com/v1/automations \
  -H "Authorization: Bearer atn_live_<your key>" \
  -H "Content-Type: application/json" \
  -d '{"name":"Monday visibility report","instruction":"summarise last week","trigger":"weekly","timezone":"Europe/London","run_at_minute":540}'

Parameters

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

Name	In	Type	Default	Notes
name*	body	string	—	What it is called in the listing and in the dashboard.
instruction*	body	string	—	What it should do each run, in plain language. This is the automation's behaviour, not a description of it.
trigger*	body	enum	—	manual, once, daily or weekly. manual and once never fire on a clock.
tools	body	string[]	—	An optional allow-list of tool names. Omit it to allow everything the plan includes.
timezone	body	string	UTC	An IANA zone the schedule is written in, such as Europe/London.
run_at_minute	body	integer	—	Minutes past local midnight, 0 to 1439. Only meaningful for daily and weekly triggers.

The response (201)

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

{
  "id": "aut_71cd",
  "name": "Monday visibility report",
  "instruction": "summarise last week",
  "trigger": "weekly",
  "tools": [],
  "status": "active",
  "timezone": "Europe/London",
  "run_at_minute": 540,
  "last_run_at": null
}

What goes wrong, and what it means

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

A manual or once automation never fires: Neither trigger runs on a clock. A manual automation waits to be triggered, and a once automation fires a single time and then reports done.
The schedule drifts by an hour twice a year: The timezone was left at the default. The schedule is written in the zone you give it, which is what keeps nine in the morning at nine across a daylight-saving change.
An automation does more than expected: The tools allow-list was omitted, which allows everything the plan includes rather than nothing. Naming tools is how an automation is restricted.

What this endpoint cannot tell you

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

Creating an automation reveals nothing about what it will cost. Creation is free and each run bills like a manual one, so a daily automation is a recurring charge decided at creation time and paid every day afterwards.
The instruction is executed rather than parsed, so this endpoint cannot tell you whether the instruction is a good one. An ambiguous instruction produces a plausible answer to a different question, on schedule, without failing.

An automation is an instruction plus a trigger. That is genuinely all it is, and the simplicity is what makes this endpoint worth understanding carefully: what you send here is not configuration for a report builder, it is a sentence that will be executed by an agent on a schedule, indefinitely.

The instruction is the behaviour

The instruction field is written in plain language and it is not a label. Whatever it says is what the automation attempts each time it fires. That is powerful and it is also the source of the most common disappointment, because a vague instruction does not fail — it produces a confident answer to a slightly different question, every week, until somebody reads one closely.

The instructions that hold up over months tend to name the window, the slice and the output. "Summarise last week" is a starting point. "Compare the last seven days against the previous seven for the buying-intent topic, and list only prompts whose change cleared significance" is an instruction that will still mean the same thing in March.

Four triggers, two of which are not schedules

daily and weekly fire on a clock. manual and once do not: a manual automation waits to be triggered, and a once automation fires a single time and then settles into a done status. Both are useful — manual is how you keep a complicated, reusable instruction around without paying for it on a cadence — but neither will produce anything on its own, and expecting them to is the commonest misreading of the field.

Timezone is not optional in practice

The schedule is stored as an IANA zone plus minutes past local midnight. The default is UTC, and leaving it there is fine only if you genuinely want UTC.

The reason to set it is daylight saving. A weekly report defined as 540 minutes in Europe/London arrives at nine in the morning in London all year. The same report defined in UTC arrives at nine for half the year and ten for the other half, and the shift is exactly the kind of thing that gets attributed to a product bug six months later.

The allow-list allows everything when empty

tools restricts what the automation may reach for. Omitting it does not restrict anything: it allows everything the plan includes. That inversion is worth saying plainly because the natural reading of an absent list is "nothing".

Restricting is therefore an explicit act, and it is a reasonable one for anything running unattended. An automation that only needs to read metrics does not need access to the tools that delete a prompt or spend credits on an agent run, and naming its tools is the cheapest way to bound what an unattended instruction can do on a bad day.

The cost decision is made here

Creation itself is free. Every run afterwards spends credits like a manual one, which means the moment you choose daily you have signed up for a recurring charge that nobody will be present for. The honest way to size that is to run the same instruction once by hand first, see what it consumes and whether the answer is worth having, and only then put it on a cadence.

Its twin on the other surface

The create_automation MCP tool takes the same six arguments and needs the write scope. It is the one write tool where the assistant's convenience is most obviously worth it — describing a weekly job out loud is much faster than writing JSON — and also the one where it is worth reading back what got created before walking away.

Questions people ask

Does creating an automation cost credits?: No. Creation is free. Every run it performs spends credits like a manual run, which is where the ongoing cost sits.
What is the difference between manual and once?: Neither runs on a clock. Manual waits to be triggered and can be triggered repeatedly; once fires a single time and then reports its status as done.
How do I restrict what an automation may do?: Name the tools it may use in the allow-list. Omitting the list allows everything the plan includes, so restriction is an explicit act.
Why does the timezone matter if I set the minute anyway?: Because the minute is minutes past local midnight in that zone. Without a zone the schedule is in UTC and drifts against local time twice a year.
Can I change an automation after creating it?: This endpoint creates. For the current definition read the single-automation endpoint, and for removing one entirely there is a separate destructive call.

Sources

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

The Attensira API reference states that creating an automation is free while each run it performs spends credits.
docs.attensira.com · retrieved 2026-09-04
“Creating is free; each run it performs spends credits.”
The API reference states that the tools field is an optional allow-list of tool names the automation may use, and that omitting it allows everything the plan includes.
docs.attensira.com · retrieved 2026-09-04
“Optional allow-list of tool names it may use. Omit to allow everything the plan includes”

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