Production checklist

Publishing, API keys, notifications, outcomes, retries, concurrency, and monitoring.

Your integration works. This page covers how to get it into production.

The workflow’s deploy page tracks the four steps below and shows your progress.

---

Four steps

1. Publish a version

   The API runs the published version.

   Publish again after every change you want in production. See Versions and publishing.

2. Create an API key

   Click your profile picture at the bottom left, then API Keys. Or open platform.asteroid.ai/keys.

3. Use our SDK to integrate into your codebase

   See our SDKs and our API Reference.

4. Set up notifications

   Open the workflow’s Notifications page. Add a webhook or a Slack channel, and subscribe to failures and other events that you want to be notified about.

   See Webhooks and Slack.

---

Handle outcomes

Your code must handle two groups.

1. Every outcome label the workflow declares. These are the expected endings, success and failure alike.
2. A label you do not recognise. If a new outcome is added to your workflow, make sure that your code is robust enough to catch this outcome and alert, rather than crashing.

The labels below are placeholders. Replace them with the outcomes your own workflow declares.

if (execution.status !== 'completed' || !execution.executionResult) {
  return escalate({ status: execution.status, url: execution.platformUrl });
}

switch (execution.executionResult.outcome) {
  case 'slots_found':
    return saveSlots(execution.executionResult.result);
  case 'no_slots_available':
    return scheduleRetry(execution.executionResult.result.nextAvailable);
  default:
    return escalate({ outcome: execution.executionResult.outcome, url: execution.platformUrl });
}

---

Decide your retry rule

Sometimes, things happen that cause your executions to fail. The website might have updated to add a new form page that your workflow isn’t expecting. The website might be experiencing an outage.

Runs might not be idempotent. Running a booking workflow twice books two appointments. If multiple runs of a workflow have side effects on the real world, it’s worth spending some time on your retry flow.

You can tag every run with your own internal IDs using metadata, then search before you retry.

# Did we already run this order?
curl "https://odyssey.asteroid.ai/agents/v2/executions?agentId=$ASTEROID_AGENT_ID\
&metadataKey=orderId&metadataValue=ORD-88213" \
  -H "X-Api-Key: $ASTEROID_API_KEY"

GET /executions also filters by status, phase, outcomeLabel, triggerSource, workflowVersion and createdAfter. The same query sweeps for runs your webhook handler missed while it was down.

---

Plan for concurrency

One agent profile holds one browser session. Two executions that share a profile can overwrite each other’s state when they terminate. Both can then fail in confusing ways.

Run the same workflow against the same portal more than once at a time? You can use a profile pool and pass agentProfilePoolId instead of agentProfileId. See Agent profiles.

Profile pools give each execution its own browser state or credentials. Even if the credentials are the same, having each execution use its own state is beneficial for not causing cookies to be overwritten.

Profile pools allow you to control concurrent access to a profile; you can make it so that a profile can only be in use by one execution at a time.

When the pool or your organisation’s concurrency limit is full, an execute call fails by default. Send "onCapacityLimit": "queue" and the platform holds the execution as queued, then starts it when a slot frees. Your caller gets the execution ID at once and polls it as usual. See Queue when capacity is full.

For a known list of work, you might want to use a batch. A spreadsheet of patients or a day of claims fits this. A batch carries concurrency limits and progress tracking.

---

Protect your API key

• Keep the key server-side. Never put it in browser or mobile code.
• Use one key per system, so revocation is easy.
• Keep keys out of logs.

See Security for our certifications and data handling.

---

Know where to look when it breaks

Question	Where to look
Did my request arrive?	The Executions page, filtered to API-triggered executions
What did the workflow do?	The execution timeline and its session recording
Why did it decide that?	executionResult.reasoning, and the reasoning in the timeline
Is this execution typical?	The workflow’s Stats page
Which version ran?	workflowId on the execution, or the version on the execution page

Debug your workflows walks through a broken execution step by step.

Send platformUrl with any support question so that our team can take a look.

---

Related

Call a workflow from your code

The whole integration on one page

Webhooks and Slack

Get told when an execution finishes or fails

Batch executions

Run one workflow over many rows

Debug your workflows

Find out why an execution went wrong