Give browser automation a versioned lifecycle
Browser Workflows operates on a distinct control plane separate from the Data API. Structure your automation hierarchy as workspace, project, environment, workflow, immutable version, and run. Once definitions are published, they cannot be altered; instead, update them by releasing a new version.
- Choose a project and environment for the integration.
- Create a declarative definition and output schema, then validate the draft.
- Publish and activate the version before starting a run or batch.
- Inspect the run status, output, action trace, and available masked evidence.
Typed steps, with explicit boundaries
The initial contract includes actions like navigate, click, fill, select, wait_for_selector, assert, extract, and download. For instance, a workflow might navigate to a catalog, pause until the product container loads, verify its presence, and then extract the records.
This is a linear sequence. Do not design integrations that assume loops, branches, arbitrary JavaScript, or a free-form graph. Validate the definition through the workflow API before publication.
Run safely across environments
Server integrations rely on Browser Workflow credentials scoped to a specific project and environment. Assign only the required scopes and provide an Idempotency-Key for repeatable write operations. If a conflict occurs, retrieve the resource again before attempting a retry.
Terminal webhooks are sent at least once; validate their signature and timestamp, then remove duplicates using the event ID. Evidence and signed download URLs have expiration times and should not be treated as permanent public links. Managed CDP requires a dedicated scope and a valid, unexpired session.