--- title: "Rocketbot Integration" description: "Rocketbot 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." url: https://flowrunner.ai/integrations/rocketbot date_modified: 2026-09-04T14:59:52-07:00 --- # Rocketbot [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Rocketbot 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. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 9 actions · API key · available [Rocketbot website](https://rocketbot.com/) · [Platform Documentation](https://rocketbot.com/) · Capability data verified 2026-08-25 1. Approved records arrive that the RPA robot was built to process 2. List Projects resolves the process token, which is the only identifier the run and upload routes accept 3. Each record is checked against the form's own fields, which come from the form's design rather than the API 4. Add Queue Item submits the data to the Xperience form and queues it for the robot 5. Start Robot begins the process, which answers only that the instruction was accepted 6. List Pending Queue Items and Get Queue Item report what the robot has and has not claimed 7. Items still unclaimed after the expected window stop here for the process owner to investigate ## 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](https://flowrunner.ai/concepts/connectors) 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](https://flowrunner.ai/concepts/human-in-the-loop) section. ### Without FlowRunner **Robots started by hand**: Somebody opens the Orchestrator and clicks run, because nothing upstream can **No answer about what happened**: The start call reports only that it was accepted, and nothing else reports the outcome **Two robots on the same record**: Without a claim step, concurrent robots can pick up the same queue item ### With FlowRunner **Robots started by the systems that create the work**: The upstream event queues the data and starts the process in the same flow **The queue is the status**: Claimed, processed, and still pending are read from the queue rather than guessed **One robot per item, by design**: Items are locked before processing and marked when finished, so nothing is done twice ## 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](https://flowrunner.ai/integrations/snowflake), or a row is finalized in [Google Sheets](https://flowrunner.ai/integrations/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](https://flowrunner.ai/integrations/slack) or [Microsoft Teams](https://flowrunner.ai/integrations/microsoft-teams), and a stuck batch opens a ticket in [ServiceNow](https://flowrunner.ai/integrations/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 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 9 actions ### Projects 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. **Work at Rocketbot?** This integration exposes Rocketbot to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/rocketbot. Site index: https://flowrunner.ai/llms.txt