BrowserAct

BrowserAct is an AI browser automation and scraping platform. Workflows run the automations you built in the BrowserAct dashboard or the vendor's templates, follow each task to its result, and pause, resume, or cancel runs.

Verified 12 actions API key available

BrowserAct website Platform Documentation Capability data verified 2026-08-25

The weekly confirmation check comes due for every open purchase order on a supplier portal

Get Workflow reads the workflow's input parameter definitions, which is the only place the names it expects are written down

Run Workflow starts the automation with those exact names and returns a task id

Get Task Status is polled on its finished flag rather than on one status string, because failed, canceled, and paused all arrive as healthy responses

Get Task returns the run's step by step progress and its output once the task lands

The confirmations post to the procurement channel, with the run's steps attached whenever something expected is missing

When a task comes back paused, a person reads the steps and decides whether to resume the run or end it

What This Integration Enables

BrowserAct workflows are built in the BrowserAct dashboard, by a person, with a browser open. This API runs them. That division is the whole shape of the connector and it is worth being direct about, because it decides what a FlowRunner agent is actually doing here: orchestrating an automation it did not author and cannot read. The twelve operations are list, read, run, follow, resume, and cancel. There is no create.

That is a stronger position than it sounds. The people who know how a supplier portal behaves are the ones who work in it, and they can encode that knowledge without waiting on an engineer. What they cannot do is put that automation into a business process, on a schedule, with its output going somewhere useful and its failures reaching a person. Get Workflow returns the input parameter definitions, which is the only place a run's expected input names are stated, so a flow can validate before it spends. Get Task Status is the light call for a polling loop and Get Task returns the step by step trace that explains a run which produced the wrong thing. List Workflow Templates runs the vendor's own templates with nothing built in the dashboard at all, and Proxy Region on a template run decides which country the browser appears to be in, which changes what a geo varying site shows. FlowRunner supplies the part BrowserAct does not: the schedule, the surrounding systems, and the human-in-the-loop step for the moments an automation running inside somebody else's website should not resolve on its own.

Without FlowRunner

Portals with no API The data a team needs exists only behind a supplier's login, and somebody visits fourteen sites every Monday

Runs that report nothing wrong A task given the wrong input names produces an empty result rather than an error, so a quiet failure looks like a quiet week

Automations that stop and wait A run pauses partway through and sits there until someone happens to open the dashboard

With FlowRunner

Portal work on a schedule The automation runs when the process needs it, and its output lands where the rest of the workflow already is

Empty results caught Input names are read from the workflow itself before the run, so an empty result means an empty page rather than a typo

Pauses that reach a person A paused run becomes a message with the steps attached, and the decision to continue or stop is made deliberately

Use Case Scenarios

Purchase order confirmations pulled from supplier portals

A buying team works with suppliers whose portals have no API and no intention of getting one. A person builds one BrowserAct workflow per portal, taking a purchase order number as input. Each week the agent reads the open orders from PostgreSQL, calls Get Workflow for the portal's parameter names, and runs each order through Run Workflow. It follows every task with Get Task Status and collects the outputs with Get Task. Confirmed dates go back onto the order records, and the ones the portal shows as changed post to the procurement channel in Slack with the run's steps attached so the buyer can see what the browser actually saw.
Regional availability checked from the right country

A category manager needs to know what a supplier's public catalog shows in three markets, because price and availability differ by region. Rather than building anything, the agent uses List Workflow Templates to find the vendor's own catalog template, calls Get Workflow Template for its inputs, and runs it three times through Run Workflow Template with a different Proxy Region each time, chosen from List Proxy Regions. The three results land side by side in Google Sheets, each labeled with the country it was collected from, because a number collected from the wrong region is worse than no number at all.
Finding the runs nobody collected

Long running tasks get started and then orphaned when a flow ends, a schedule overlaps, or somebody triggers a run by hand. Once a day the agent calls List Tasks filtered on running and on paused, matches them against the task ids its own flows recorded, and reports the difference. Running tasks it recognizes are followed to completion and their outputs written to Airtable. Paused tasks are routed to a person. Tasks nobody can account for are listed rather than canceled, because ending a run is permanent and the agent does not know what it would be ending.

Human-in-Loop Highlight

A BrowserAct task pauses when the workflow it is running asks for something. At that moment the run is sitting inside a live website, partway through whatever it was doing, holding whatever state it has already created there. Two operations apply and they are not symmetric. Resume Task continues the run from where it stopped. Cancel Task ends it immediately and permanently, and a canceled task cannot be resumed the way a paused one can, so whatever half completed thing the run left behind on the supplier's site stays exactly as it is with nothing to finish it. An agent cannot judge which is right, because it did not write the workflow and cannot see the steps the dashboard defines. What it can do is bring the evidence: the trace from Get Task showing every step the run completed, the page it stopped on, and how long it has been waiting. Then it asks the buyer who owns that supplier relationship: "This run submitted the reschedule request and paused before confirming it. Resume and let it finish, or cancel and handle the confirmation by hand?" One of those answers leaves a half finished request in a supplier's system. Which is precisely why a person picks it.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

12 actions

Workflows

List Workflows Returns the workflows in the workspace. The starting point, because workflows are built in the BrowserAct dashboard rather than through this API.
Get Workflow Returns a workflow's configuration including its input parameter definitions. Not optional, because this is the only place the input names a run expects are stated, and a run given the wrong names produces an empty result rather than an error.
Run Workflow Starts one of the workspace's workflows and returns a task id. The run is asynchronous, so the result arrives through polling or a callback rather than in this response.

Templates

List Workflow Templates Returns BrowserAct's own workflow templates, searchable by keyword. A template runs without anything being built in the dashboard first.
Get Workflow Template Returns an official template's configuration and its input parameter definitions, under the same rule as a workflow: this is the only place the expected inputs are named.
Run Workflow Template Starts one of the vendor's official templates and returns a task id. This is also the only operation that takes a proxy region, which decides which country the browser appears to be in.
List Proxy Regions Returns the country codes a template run accepts as its proxy region.

Tasks

Get Task Returns everything about a task: its status, its step by step progress, its output once finished, and its failure details if not. The steps are where a run that produced the wrong thing explains itself.
Get Task Status Returns only a task's current status plus computed flags for whether it has finished and whether it succeeded. The right call for a polling loop, and the reason a loop should branch on the finished flag rather than on one status string.
List Tasks Returns the workspace's task history, filterable by status and by workflow. How a flow finds the runs it started earlier and never collected.
Resume Task Continues a paused task from where it stopped. It applies only to a paused task, not to one that has finished, failed, or been canceled.
Cancel Task Stops a running task immediately. A canceled task cannot be resumed, so this ends that run and its credits, which also makes it the stop spending button for a task pointed at the wrong input.

Frequently Asked Questions

What can FlowRunner do with BrowserAct?

FlowRunner agents can run List Workflows, Get Workflow, and Run Workflow in BrowserAct, plus 9 more actions.

Does connecting BrowserAct to FlowRunner require OAuth?

No. BrowserAct connects to FlowRunner with an API key, no OAuth flow required.

Can BrowserAct trigger a FlowRunner workflow automatically?

BrowserAct doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with BrowserAct

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us