task_ (object type task); runs have the prefix trun_ (object type task_run).
Tasks consume credits. Every run is one or more AI operations (messages, media generation, web research, calls), all metered pay-per-call. The Task object tracks lifetime spend in
total_credits_consumed; each run reports its own credits_consumed. Check your balance with GET /usage.Anatomy of a Task
POST /v1/tasks accepts these fields (params are top-level — no task wrapper):
The task’s display name.
An optional human description.
What you want the agent to do — the instruction it runs every time.
One of
immediate, cron, interval, once, event. See below.business (default) or engineering. Business operates your account through the API; engineering writes and ships code on a Site.autonomous, supervised, or read_only. Controls how much human oversight each run requires.Where results are delivered: any of
notification, email, telegram, discord, slack.For
event triggers: filters that must match the incoming event for the task to fire. See Events.The Site (
site_...) the task works on. Its repo is mounted as the agent’s workspace. Defaults to your account’s default site. Most relevant for the engineering agent.Override the model used for the run.
Cron schedule (for
trigger_type: cron).Seconds between runs (for
trigger_type: interval).When to run (for
trigger_type: once).Timezone for
cron/scheduled_at, e.g. America/New_York.After this time the task stops running.
Whether the task is enabled. Set
false to pause without deleting.next_run_at, last_run_at, total_runs_count, consecutive_failure_count, and total_credits_consumed.
Choosing an agent
| Agent | What it does | When to use it |
|---|---|---|
business (default) | Operates your business through the API: products, checkouts, customers, email, socials, web research, calls. | Marketing, ops, sales, reporting, follow-ups. |
engineering | Writes and ships code on a Site — the repo is mounted as its workspace; it can build and deploy. Scope it with site_id. | Website changes, bug fixes, new features, deploys. |
Triggers
trigger_type decides when a task runs. There are five, each with its own scheduling field.
immediate — run once, right now
Fires a single run the moment you create the task. Good for kicking off ad-hoc work asynchronously.
cron — run on a cron schedule
Recurring, calendar-based. Pair cron_expression with a timezone.
interval — run every N seconds
Fixed cadence, independent of the wall clock. Set interval_seconds.
once — run a single time at a future moment
Schedule a one-off with scheduled_at.
event — run when something happens
The task lies dormant until a matching event fires (e.g. order.paid). Constrain which events trigger it with event_conditions.
event_conditions works.
Autonomy: approval_mode
approval_mode is the human-in-the-loop dial. It decides whether a run can act on its own, must pause for your approval, or can only observe.
| Mode | Behavior |
|---|---|
autonomous | The agent runs end-to-end and takes actions (writes, sends, deploys) without asking. Best for trusted, well-scoped tasks. |
supervised | The agent pauses at decisions that require approval. The run enters a needs-input state and waits for you to approve, deny, or provide input before continuing. |
read_only | The agent can read and analyze but cannot make changes. Best for reporting, audits, and research. |
The supervised loop
A supervised run pauses instead of acting, which fires thetask_run.needs_input webhook event (and notifies you via your delivery_methods). You review it in the Crevio dashboard — approving the pending action or giving the agent direction — and it resumes from where it stopped. The cycle:
Run starts and reaches a checkpoint
The agent does its work until it hits an action that needs approval (or it needs information from you).
Run pauses in needs_input
The Task Run status becomes
needs_input; task_run.needs_input fires and you’re notified.You review and respond in the dashboard
Approve the pending action or give the agent more direction from the Crevio dashboard or notification. (Over the API you can read run state and update its
status/summary — see below.)Task Runs
Each execution of a Task is a Task Run (trun_, object type task_run). Runs are read-mostly: you list and get them to inspect what happened, and PATCH them to update their status/summary.
The run object
| Field | Description |
|---|---|
task_id | The parent task (task_...). |
status | Lifecycle state (e.g. running, needs-input, completed, failed). |
summary | The agent’s natural-language summary of what it did. |
error_message | Populated when the run failed. |
input_tokens / output_tokens | Token usage for the run. |
credits_consumed | Credits this run cost. |
tool_calls_count | How many API/tool calls the agent made. |
duration_ms | Wall-clock duration. |
started_at / completed_at | Timestamps. |
List and get runs
- cURL
- MCP (agent)
{ "object": "list", "data": [...], "has_more": bool }.
Updating a run’s state
PATCH /v1/task_runs/{id} updates a run’s state. The body accepts:
pending, running, completed, failed, or needs_input.The run’s summary text.
An error message for a failed run.
Recorded input token count.
Recorded output token count.
needs_input, you resume or close it out by PATCHing status (and optionally summary/error_message) — for example set status to running to release it, or to completed/failed to close it.
The API lets you read run state and update
status/summary — there is no field for sending free-form instructions back to the agent. The interactive back-and-forth for a supervised run (approving a pending action or giving the agent more direction in plain English) happens in the Crevio dashboard and notifications, not over the API.Managing tasks
{ "id": "task_abc123", "object": "task", "deleted": true }.
Next steps
Events & Event Sources
Fire event-Tasks from internal events and third-party apps.
AI & Agents overview
How Tasks fit into Crevio’s broader agentic model.
Webhooks
Get notified when runs complete, fail, or need your input.
Usage & credits
See how task runs are metered and check your balance.

