Browserflow
Developer ToolsBrowserflow automates browser tasks, most often on LinkedIn. Workflows start a flow you built in Browserflow and pass values into it, with results arriving through the flow's own webhook.
What This Integration Enables
Browserflow has one public API route: start a flow. That is not a thin connector, it is the product's own shape, and the honest page says so. Everything else happens in Browserflow itself. The flow is built there, the browser session is connected there, and the results come back through a webhook configured on the flow's own settings rather than through anything this API returns. Run Flow accepts input variables, and that single feature is what makes the arrangement worth having: one flow written once can be pointed at a different profile, company, or search on every run, instead of one flow per target.
The pattern that follows is a two flow pattern. A webhook triggered flow in FlowRunner receives the results, and a second flow calls Run Flow to start the work. Between them sits everything Browserflow does not do: the list that decides who is worth researching, the deduplication against the CRM, the enrichment that continues after the findings land, and the approval that happens before anything starts. That last one is not decoration here. Run Flow answers with an acknowledgement and no run id, and there is no route to poll, no route to cancel, and no way to ask whether the run finished. FlowRunner's human-in-the-loop step is not a nicety layered on top of a controllable system; on this connector it is the only control that exists, and it only works before the call.
Without FlowRunner
With FlowRunner
Use Case Scenarios
-
Account research that feeds the CRM instead of a spreadsheet
An account reaches the research stage in HubSpot. The agent builds the input variables from the account record, the rep approves the batch, and Run Flow starts the Browserflow flow for each target. Findings arrive at a webhook triggered FlowRunner flow, which matches each result back to its account, writes the summary onto the record, and posts a short brief to the rep in Slack before their first call. The rep never opens Browserflow and never exports anything.
-
One flow, many targets, driven from a list
Rather than a separate Browserflow flow per campaign, a single flow takes a URL as an input variable. The FlowRunner side reads targets from Google Sheets, enforces its own per day ceiling, and starts one run per row on a schedule spread across the working day rather than in a burst. Results land back through the webhook and update the same sheet, so anyone can see what has been covered and what has not. Changing the campaign means changing the list, not rebuilding the automation.
-
Findings that continue into a sequence, with a person in the middle
Research results arrive at the webhook flow and the agent drafts the outreach: the hook it found, the suggested opener, the sequence it belongs in. Nothing sends. The draft goes to the rep with the source of every claim attached, and the rep edits, approves, or discards. Approved drafts are enrolled through Instantly or written to Attio for the owner to work manually. The research is the agent's; the message that goes out under a person's name stays that person's.
Human-in-Loop Highlight
The gate on this connector is unusual because of what is absent from it rather than what is in it. Run Flow returns an acknowledgement with no run id. There is no status route, no cancel, and no way to ask what the run did. The moment the call is made, the automation is running in a browser session belonging to a real person's account, taking real actions on a platform with its own limits and its own terms, and this API offers nothing that reaches back in. Approval after the fact is not a worse option here, it is not an option at all. So FlowRunner puts the whole decision before the call: the agent assembles the target list, removes anyone already in sequence or owned by another rep, sizes the batch against what one account should reasonably do in a day, and posts it with the exact text the flow will use. "This starts 40 profile visits and 12 connection requests from your account this afternoon, with this note. Approve, trim the list, or change the note." The rep answers, and only then does Run Flow fire. The agent did the assembling, the deduplication, and the sizing. The person accepted the consequences under their own name, which is the only place that decision could have honestly sat.
Agent Capabilities
1 actionsFlows
1- Run Flow Queues a Browserflow flow to run in the cloud, with input variables substituted at run time so one flow can be pointed at a different target on every run. It answers with an acknowledgement and no run id, there is no route to poll or to cancel, and results reach you only through the webhook configured on the flow's own settings in Browserflow. The flow must also be enabled to run in the cloud, since one that only runs in the browser extension cannot be started here.
Frequently Asked Questions
What can FlowRunner do with Browserflow?
FlowRunner agents can run Run Flow in Browserflow.
Does connecting Browserflow to FlowRunner require OAuth?
No. Browserflow connects to FlowRunner with an API key, no OAuth flow required.
Can Browserflow trigger a FlowRunner workflow automatically?
Browserflow doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Other Developer Tools integrations
Start building with Browserflow
Free plan, no card required. Connect in minutes.