Platforms

Define websites and desktop apps with handler identifiers, an optional target, and metadata for use in task scripts.

A platform represents a website or desktop app your automations interact with. Platforms are defined at the workspace level and shared across agents and tasks.

Creating a platform

Open Platforms in your workspace sidebar and click New platform.

Field	Description
Name	Human-readable label shown in the UI
Handler	Unique identifier referenced in DSL scripts
Target	Optional default open target. Browser platforms use an http(s) URL. App platforms use a guest launch command. The value a session actually opens is stored on the agent binding.
Description	Optional notes for your team
Metadata	Optional JSON for custom configuration

Handler naming

Handlers are the bridge between your task scripts and configured platforms. Rules:

Use lowercase letters, numbers, and underscores
Must be unique within the workspace
Referenced directly in DSL — no declaration needed in scripts

Example: a platform with handler customer_portal is used as:

flow {
  in customer_portal {
    click { css "#submit" }
  }
}

Platform linkage in tasks

When you create a task, link it to the platforms it uses. This:

Validates that referenced handlers exist
Shows which sites a task touches in the UI
Helps the runtime prepare the correct browser context

A single task can span multiple platforms:

flow {
  in login_portal {
    // authenticate
  }
  in crm {
    // extract data
  }
}

Platforms vs. agent configuration

Platforms define what sites and apps exist, including an optional default target. Agent-platform bindings define how an agent accesses them — the target that session actually opens, credentials, captcha settings, and concurrency limits. Saving an agent platform always stores that target on the binding, including when it matches the platform default. See Agents and Credentials.

Best practices

Use descriptive handler names that match the site's purpose (billing_portal, vendor_login) rather than generic names (site1).
Set the target to the page or command agents should open first — usually a login or dashboard URL, or the desktop app's launch command.
Keep metadata for team notes or external system IDs your integrations need to correlate.