Rocketbot
Developer ToolsRocketbot Orchestrator runs RPA robots and the Xperience form queues that carry data into them. Workflows start robots, deploy new robot files, add and update queue items, and read assets.
What This Integration Enables
Rocketbot Orchestrator has a property worth naming plainly, because everything about how you build on it follows from it. Start Robot answers that the instruction was accepted and nothing more. No run id, no job handle, no status route to ask afterwards. Once a robot is running there is no way to query whether it finished or what it did. Anything a workflow needs to know has to come back through the robot itself.
That is not a criticism, it is a design constraint, and it points directly at what the rest of the connector is for. The Xperience form queue is the channel data goes in through and the channel status comes back out of. Add Queue Item is how a workflow passes input to an automation that takes no parameters. Set Queue Item Status is the handshake that stops two robots doing the same work: lock the item, process it, mark it done. List Pending Queue Items is the work list, and Get Queue Item is where the submitted data actually lives, parsed into fields rather than left as the JSON string the API returns.
So FlowRunner builds the observability around the robot rather than pretending the robot provides it. Agents queue validated work, start the process, watch the queue for claims and completions, and raise a person when items sit unclaimed. The one operation that changes what the robot is, rather than what it is given, is the subject of the human-in-the-loop section.
Without FlowRunner
With FlowRunner
Use Case Scenarios
-
The robot fed by the systems that generate its work
An approved request lands in a ticketing system, a record clears validation in Snowflake, or a row is finalized in Google Sheets. The agent calls List Projects to resolve the process token, validates the payload against the fields the Xperience form defines, and calls Add Queue Item. The form has to have its API submission option enabled in Roc Xperience for this to work, and nothing in the API can turn that on, so the connection is confirmed once during setup rather than debugged during a run. Start Robot then begins the process. The person who used to open the Orchestrator and click run now approves the record and nothing else.
-
Reading progress from the only place it exists
Because the start call reports nothing about the run, a monitoring workflow watches the queue instead. List Pending Queue Items returns the ids still unprocessed for a form, and Get Queue Item fetches each one's submitted data. The agent compares the pending set against what it queued: items that have been claimed are in progress, items that moved to processed are done, and items still unclaimed past the expected window are the ones worth a message. The summary posts to Slack or Microsoft Teams, and a stuck batch opens a ticket in ServiceNow with the item list attached.
-
Two robots, one record, no collision
When more than one robot works the same queue, the claim matters more than the processing. A FlowRunner side workflow calls Set Queue Item Status to lock an item before any work begins on it, then marks it processed when the work completes. The vendor's own documentation and its example disagree on the field name for the lock, so the connector sends both spellings, because guessing wrong leaves the item unlocked and available to another robot with no error to say so. Getting that detail right is the difference between a queue that serializes correctly and one that occasionally pays the same invoice twice.
Human-in-Loop Highlight
Upload Robot attaches a robot file to an existing process, replacing whatever was there, immediately, with no version history available through this API. The next scheduled run uses the new file. Now put that next to the other fact on this page: Start Robot reports nothing about what the robot did. So a deployment here removes both of the things that normally make a deployment recoverable. There is no previous version to roll back to through the connector, and there is no run outcome to tell you that rolling back is needed. A bad robot file does not announce itself. It just quietly does the wrong thing to real records on its next schedule.
That is why FlowRunner never lands a robot file unattended. The agent does everything up to the write: it resolves the process token, confirms the target process and the robot currently assigned to it with List Projects, and posts the deployment for confirmation. "Uploading orders-reconcile.zip to process CEDLU6FK79BOLPUM. It replaces the file currently attached, immediately, and the next scheduled run at 02:00 uses it. This API keeps no previous version and reports nothing about run outcomes. Confirm?" The automation lead confirms, and the agent uploads. The gate is not here because the operation is dramatic. It is here because both the undo and the evidence are missing, and one human read of the filename is the only check that remains.
Agent Capabilities
9 actionsProjects
1- List Projects Returns every project in the Orchestrator with its processes and the robot assigned to each. The starting point for everything else, because it is the only place the process token comes from, and the token rather than the numeric id is what the run and upload routes need.
Robots
2- Start Robot Runs the robot attached to a process. The integration point that lets an external system kick off an RPA process. It answers only that the instruction was accepted, so anything a workflow needs to know has to come back through the robot itself.
- Upload Robot Attaches a robot file to an existing process, replacing whatever was there. The deployment step, and what this page's human gate exists for: it takes effect immediately, keeps no version history through this API, and cannot create a process that does not already exist.
Queues
5- List Queue Items Returns the queue items of every Xperience form in the Orchestrator, optionally within a date window. The audit view across all forms, including whether a robot has claimed each item.
- Add Queue Item Submits data to an Xperience form and queues it for a robot. This is how a workflow passes data into an automation, since starting a robot takes no parameters at all. The form's API submission option has to be enabled in Roc Xperience first.
- List Pending Queue Items Returns the ids of one form's items that are still unprocessed. The work list, and the poll target for a monitoring workflow. It returns ids and little else, so payloads come from Get Queue Item.
- Get Queue Item Returns one queue item's submitted form data. The API returns the data as a JSON string rather than an object, so the connector parses it into fields and keeps the original alongside.
- Set Queue Item Status Marks a queue item processed or not, and locks or unlocks it. The handshake that stops two robots doing the same work, and the connector sends both of the field spellings the vendor's own documentation and example use.
Assets
1- Get Asset Returns an Orchestrator asset by name and instance. An asset can be a credential and a password type comes back in clear, so treat the result as a secret and keep it out of logs.
Frequently Asked Questions
What can FlowRunner do with Rocketbot?
FlowRunner agents can run List Projects, Start Robot, and Upload Robot in Rocketbot, plus 6 more actions.
Does connecting Rocketbot to FlowRunner require OAuth?
No. Rocketbot connects to FlowRunner with an API key, no OAuth flow required.
Can Rocketbot trigger a FlowRunner workflow automatically?
Rocketbot 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 Rocketbot
Free plan, no card required. Connect in minutes.