Cloud BOT
Developer ToolsRun Cloud BOT browser-automation bots from a flow. Cloud BOT records browser steps and replays them in the cloud, so agents can reach systems that expose no API at all.
What This Integration Enables
Cloud BOT is the deterministic option in a category increasingly dominated by agents that decide for themselves. Nobody describes a goal here. Somebody sat down, performed the task once in a browser, and Cloud BOT recorded it. What replays afterwards is that recording, on Cloud BOT's own virtual browser in the cloud, with nothing installed on anyone's machine. For a supplier portal whose form has looked the same for four years, that is not a limitation, it is the correct trade: no model in the loop means no model to surprise you, and the cost of a run is predictable.
The connector wraps that with the operational parts a flow needs. Run Bot starts a published bot with input values keyed by the bot's own input data names, and can either wait up to 25000 milliseconds for the output or return a job ID immediately. Get Job polls that job, and while it is still executing the response carries a cast URL for watching the virtual browser live, which is an unusually direct way for a person to see what an automation is doing at the moment they need to. On Bot Job Event closes the loop by registering a REST Hooks subscription on the bot, so a finished run pushes its output into the flow instead of being polled for.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Stock and price checks on a supplier portal with no API
A planning team needs current availability from three supplier portals that publish nothing machine readable. A recorded bot per supplier signs in and reads the stock table. The flow calls Run Bot with a wait time of zero, polls Get Job, and writes the returned output values into Google Sheets alongside the timestamp of the run. Because Get Bot returns the bot's input and output definitions, the flow builds its input object from the bot's own declared data names rather than from someone's memory of what the form fields were called.
Placing a replenishment order, with the approval in front of it
The same portal accepts orders through a form. A second bot records that submission. The flow does not connect the reorder point directly to that bot. It runs the read only check first, proposes a quantity, sends it to the buying channel in Slack, and only calls Run Bot for the ordering bot after a buyer approves. When the job finishes, On Bot Job Event delivers the completed job and the agent writes the supplier's order reference back to the purchase record.
Bounding a run that is taking too long
Cloud BOT jobs consume execution time whether or not they are making progress. A watchdog step polls Get Job, and when a job passes the duration its own history says is normal, the agent calls Suspend Job to stop it and free the execution time it would otherwise consume. The access token needs Suspend permission for this to work, which is worth granting when it is set up rather than discovering during an incident. Jobs that already finished cannot be suspended and the API reports them as gone.
Human-in-Loop Highlight
The specific fragility of recorded automation is that the recording is a photograph of a page taken on a particular day. A supplier redesigns their portal, moves a field, or inserts a confirmation step, and the replay has no model in it to notice that the world moved. This is why the human-in-the-loop gate on this connector sits on the evidence rather than on the click. The agent treats the last successful run as the reference. List Bot Jobs returns the execution history for a bot with its output included, so the shape of what just came back can be compared against what came back the last time everything was known to be right.
When they do not match, the agent does not retry and it does not pass the values downstream. It calls Suspend Job if anything is still running and posts: "The Northwind stock bot returned two of its four output values this run. The last good run on 28 July returned all four. This looks like the portal changed rather than a transient failure. Here is the live cast URL and the last good run for comparison. Re-record the bot, or run it once manually to see what changed?" A partially completed replay is not a smaller version of a correct one. On a portal where the next bot in the chain places an order, treating it as data is the failure, and refusing to is the product.
Agent Capabilities
7 actionsBot Execution
1- Run Bot Starts one of your published Cloud BOT browser automation bots and optionally waits for it to finish. Cloud BOT runs the recorded browser steps on its own virtual browser, so nothing is installed on your machine. A wait time of up to 25000 milliseconds returns the bot's output directly; a wait time of zero returns a job ID immediately for polling with Get Job. Input values are supplied as an object keyed by the input data names defined on the bot.
Jobs
3- Get Job Retrieves the current state and result of a single job by its job ID. Used to poll a bot started without waiting. While the job is executing the response carries a cast URL for watching the virtual browser live, and once it finishes the response carries the bot's output values.
- Suspend Job Stops a job that is still executing, freeing the execution time it would otherwise consume. The access token must have Suspend permission. Jobs that have already finished cannot be suspended and the API reports them as gone.
- List Bot Jobs Lists the execution history of a single bot, newest first by default, with optional filtering by date range, job ID range and job status. Used to audit past runs, find the job ID of a recent execution, or compare a suspect run against the last one known to be correct. Bot output can be included, though the API rejects responses larger than 4 MB.
Bots
2- List Bots Lists every bot published under your Cloud BOT public ID, always returning each bot's ID, name and description. Icon image, creation and update dates and author can be requested individually. The way to discover the bot IDs Run Bot accepts.
- Get Bot Retrieves a single bot by ID, always returning its ID, name and description. Requesting the input and output definitions reveals exactly which data names Run Bot accepts and which values the bot returns, which is the reliable way to build the input object for an unfamiliar bot.
Account
1- List Contracts Lists the Cloud BOT contracts your access token can reach, each with its public ID and public path. Run first when setting the service up, because the public ID it returns is the value the Public ID configuration item expects. Plan, owner and contact details can be requested as extra properties.
Triggers
1 triggersEvent Triggers
1- On Bot Job Event Fires when a chosen Cloud BOT bot finishes running, so a flow reacts to the bot's output without polling. Cloud BOT registers a REST Hooks subscription on the bot and posts the completed job to this trigger. The trigger can fire on every run, or only on successful runs, only on failed runs, or only on runs the service could not start.
Frequently Asked Questions
What can FlowRunner do with Cloud BOT?
FlowRunner agents can run Run Bot, Get Job, and Suspend Job in Cloud BOT, plus 4 more actions.
Does connecting Cloud BOT to FlowRunner require OAuth?
No. Cloud BOT connects to FlowRunner with an API key, no OAuth flow required.
Can Cloud BOT trigger a FlowRunner workflow automatically?
Yes. Cloud BOT supports 1 trigger that can start a FlowRunner workflow automatically.
Start building with Cloud BOT
$100 in credits. No card required. Connect in minutes.