Skip to main content

The contract

These are the basic calls that you will need to get started. Files, profiles, metadata, schedules and webhooks all build on them. The execute call returns as soon as the execution starts. The execution itself continues on our infrastructure. Poll the read call until the execution reaches a terminal status, or use webhooks to get alerted when the execution is finished.
Writing this with a coding agent? Give it https://docs.asteroid.ai/skill.md

A complete program

This program starts an execution, polls it to a terminal status, and branches on the result. Set ASTEROID_API_KEY and ASTEROID_AGENT_ID, then replace the inputs and the outcome labels with your workflow’s own.
Loop until the status is terminal. A loop written as while (status === 'running') exits the moment the workflow pauses. It then never sees the answer.

What the program needs from you

Three things: a key, a published version, and the input names.
1

Create an API key

In the platform, click your profile picture at the bottom left, then API Keys. Or open platform.asteroid.ai/keys.A key belongs to your organisation, not to one workflow. One key runs every workflow you own.
Keep the key on your server. Never ship it in browser or mobile code.
2

Publish a version

The API runs the published version of a workflow. Edits you save in the builder stay in the draft until you publish them.Open the builder and click Publish. Publish again after every change you want in production. See Versions and publishing.
An unpublished workflow returns an error when you call it. If your integration runs old behaviour, someone edited the draft and did not publish it.
3

Read the workflow's inputs

Every workflow declares named inputs. Each input has a name, a type, and a required flag. You send them as the inputs object.The workflow’s deploy page lists the exact set, at https://platform.asteroid.ai/agents/<agent-id>/deploy. It also shows the workflow ID, the outcome labels, and a ready-to-run request. Copy the names from there. Do not guess them from the instructions.

Inputs

Send one key per declared input.
The rules:
  • Input names match [a-zA-Z_][a-zA-Z0-9_]* and are unique inside the workflow.
  • Asteroid validates your values against the declared schema when the execution starts.
  • A required input with no value fails the run at once, not halfway through.
  • An omitted optional input falls back to its default.
See Inputs and outputs for how a workflow declares them.

Every field on the execute body

Every field is optional. A bare {} runs a workflow that declares no required inputs.
object
Values for the inputs the workflow declares. Keys must match the input names on the deploy page.
uuid
Run with one named agent profile — its credentials, cookies, proxy, and saved browser state. Mutually exclusive with agentProfilePoolId.
uuid
Take a free profile from a pool. Use a pool when you run the same workflow against one portal more than once at a time. Two concurrent executions on one profile overwrite each other’s session state. Mutually exclusive with agentProfileId.
array
Files staged before the execution. Stage them with POST /temp-files/{organizationId}, then pass the tempFiles array from that response straight through. Staged files expire after 60 minutes. See Workflow filesystem.
object
String keys and string values you attach to the execution. Metadata never reaches the workflow’s instructions. You can filter executions by it later.
integer
Run a specific version instead of the published one. Pin a version for a regression test, or for a customer on a fixed contract. Leave it out for normal traffic. See Versions and publishing.
object
Per-run overrides. softTimeoutMins tells the workflow to wrap up after that many minutes. variantKey scopes the execution’s shared files when the workflow uses variant mode.
A request that uses several of them:
Put your own record ID in metadata. A webhook handler then knows which row to update. You can also search for the execution before you retry it.

Reading the result

GET /executions/{executionId} returns everything about an execution.

Status tells you whether the execution finished

Those nine are the complete set. Terminal means finished: completed, failed, cancelled. Nothing leaves a terminal status.
There is no timed_out status. An execution past its timeout ends failed, or ends cancelled with the reason timeout. The cancel reasons are user_requested, timeout, no_activity, budget_exceeded, script_failed and max_steps.
A direct API call starts at starting. See Executions and statuses for the full lifecycle.

Outcome tells you what happened

completed means the workflow reached an Output node. It does not mean the work succeeded. An execution that correctly reports “this patient has no coverage” is completed. So is an execution that booked the appointment. The outcome label separates the two.
Branch on outcome, not on status. The outcome labels are the contract between the workflow and your code. Treat a new label as a breaking change, and handle the unknown label rather than crashing on it. See Inputs and outputs.
executionResult is absent when an execution never reaches an Output node. Check that it exists before you read it.
JSON and the TypeScript SDK use camelCase, so executionResult. The Python SDK exposes snake_case attributes, so execution.execution_result.

When an execution waits for a person

Two statuses mean the workflow needs an answer before it continues.
  • paused_by_agent — the workflow asked a question.
  • awaiting_confirmation — the workflow wants approval before it acts.
Reply with a user message, and the execution continues.
An unattended integration cannot answer. Treat both statuses as an escalation there: stop the poll loop, and send platformUrl to whoever handles exceptions. The program above does this.

Cancel an execution

The endpoint accepts running, paused and cancelled. It rejects any change to an execution that already reached a terminal status.

Polling or webhooks

Polling

Simple, and it needs no public endpoint. Poll every 5-10 seconds. Good for runs under about 5 minutes.

Webhooks

We call you on every status change. Better for long executions and high volume. Payloads are signed.
Faster polling does not finish an execution sooner. Set a deadline on every poll loop. A single-node workflow finishes in 30 to 60 seconds. A multi-node workflow takes several minutes. Run both if you want. Webhooks drive the normal path, and a sweep every few minutes catches anything your endpoint missed while it was down. Sweep with GET /executions. See Webhooks and Slack to set up notifications.

Look deeper into an execution

GET /executions filters by agentId, status, phase, outcomeLabel, triggerSource, workflowVersion, metadataKey, metadataValue, inputsKey, inputsValue, createdAfter, createdBefore, agentProfileIds, humanLabels and hasScriptFailures. Use it to build a dashboard, to sweep for missed runs, or to check for work you already ran:

Common errors

Nothing appears on the Executions page? Then the request never reached us. Check the base URL and the header name.

Next

Production checklist

What to settle before real traffic arrives

Agent profiles

Credentials, cookies, proxies, and pools

Batch executions

Run one workflow over many rows, with concurrency limits

Executions and statuses

The full lifecycle and its transition rules

TypeScript SDK

Client setup and the full function list

Python SDK

Client setup and the API classes