FlowRunner
PricingContact
Theme
Start Free

Create Twin AI web agents that drive a real browser to do work on sites with no API, then start and monitor their runs. Agents reach systems that were never given an interface.

1 trigger 26 actions API key available
Twin website ↗ Platform Documentation ↗ Capability data verified 2026-08-01
Twin auto-pauses the supplier portal agent's schedule after repeated consecutive failures
Agent reads List Run Events for the failed runs to see where in the browser each one stopped
Agent starts a Build run so Twin explores the changed portal and revises its own instructions
Agent diffs the revised instruction document against the previous entry in List Instruction Versions
Agent posts that diff and the failing event stream to the operations channel
Operations owner approves the revised playbook before the schedule is resumed

What This Integration Enables

Twin and Skyvern both drive real browsers toward a goal, and picking between them is not about capability, it is about how the automation is governed. Twin's distinguishing object is the instruction document: an auto-generated but human-editable playbook the agent follows on every run, exposed here with its full version history, each entry carrying the content at that point in time, a content hash and the source that produced it. Run mode executes those saved instructions. Build mode lets the agent explore the target site and rewrite them, at a higher credit cost. That is an unusual and honest design, because it makes the automation's logic a document rather than a black box.

Layer schedules on top and the picture completes. Each agent can carry one cron schedule, Twin auto-pauses a schedule after repeated consecutive failures, and List Schedules shows every unattended agent on the account with its next run time and consecutive failure count in a single call. A web agent that runs unattended, on a schedule, following instructions it is permitted to rewrite, is precisely the kind of thing that needs a Code of Conduct rather than a monitoring dashboard. The connector gives a flow every hook that governance needs: read the instructions, diff the versions, pause the schedule, cancel the run.

Without FlowRunner

Portal work stays manual A supplier or government site with no API means somebody logs in and clicks through it
Automation logic is opaque What the automation will do next run is buried in code or in a recording nobody can read
Silent drift An unattended job changes behaviour and the first sign is a wrong number downstream

With FlowRunner

Portal work runs on a schedule A cron schedule starts the agent unattended and reports what it did
A readable playbook The agent follows an instruction document a person can open, read and edit
Versioned changes Every revision of that playbook is kept, so what changed and when is answerable

Use Case Scenarios

Unattended portal extraction with a branch on outcome

A logistics team needs figures from a carrier portal that publishes no API. A schedule starts the Twin agent each morning. Rather than polling, the flow subscribes to On Agent Run Event and branches on the outcome the delivery carries, so success, partial and fail take three different paths. On success the agent reads the extracted output from List Run Events, which is where a run's output and reasoning actually live, and writes it into Google Sheets. On partial, it files a ticket in Jira with the run's event stream attached instead of publishing half a data set as if it were whole.

Version controlling an automation from outside the Twin app

A team wants agent instructions reviewed the same way code is. A flow calls Get Agent Instructions on a schedule, commits the current content to a repository in GitHub, and compares it against the previous commit. When a Build run has rewritten the playbook, the change shows up as a diff in a pull request rather than as a surprise in production. Rolling back is Update Agent Instructions with content taken from an older entry in List Instruction Versions.

Auditing what is running unattended

Nobody sets out to accumulate abandoned scheduled agents; they arrive one project at a time. A weekly flow calls List Schedules to get every schedule across the account with its next run time, paused state and consecutive failure count, then cross references List Agent Runs to see credits consumed and action counts per agent. Agents with schedules that Twin has auto-paused, and agents whose credits keep climbing with no consumer downstream, both get surfaced to the owner in Slack as a short list with names attached.

Human-in-Loop Highlight

The moment worth stopping on is the one Twin makes possible and nothing else in this category does: an agent revising the instructions it will follow forever after. Update Agent Instructions replaces the document outright rather than amending it, and a Build run is that same overwrite performed by the agent itself. Once the cron schedule resumes, whatever the new playbook says is what happens unattended, on a live supplier portal, with nobody watching. So the FlowRunner agent treats the promotion of a rewritten playbook as a decision, not a repair. It fetches both versions from List Instruction Versions, and posts to the operations channel: "The Northwind portal agent auto-paused after three consecutive failures. A Build run rewrote its instructions. The new version adds a step that clicks Confirm on the shipment dialogue, which the previous version did not do. Approve this playbook and resume the schedule, roll back to version 7, or leave it paused?" A person reads the diff and decides. Until they do, the agent stays paused rather than resumed, because a paused schedule costs nothing and a wrong playbook running nightly against a live portal costs a great deal.

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

26 actions

Agents

5
  • List Agents Lists the Twin agents on the authenticated account, newest activity first, optionally scoped to a single workspace. Results are cursor paginated. Each agent includes its latest run ID, latest run status and whether that run has finished, which allows polling without a separate run lookup.
  • Get Agent Retrieves a single agent by ID, including its name, owning workspace, unread flag and the identifiers and status of its most recent run. Used to check whether an agent's latest run has finished before reading its events.
  • Create Agent Creates a new agent and returns the full agent object. Every field is optional: leave them empty for a blank agent, set a workspace to file it immediately, or derive it from an existing agent to clone that configuration as a starting point. The new agent has no instructions until they are written or a Build run produces them.
  • Delete Agent Permanently deletes an agent along with its instructions, schedule and run history. This cannot be undone. Twin returns no body on success, so the action reports the deleted agent ID.
  • Move Agent To Workspace Moves an agent into a different workspace. Agents in the same workspace share context and can collaborate, so this is how an agent is grouped with the ones it should work alongside.

Instructions

3
  • Get Agent Instructions Returns the current instruction document for an agent, the auto-generated and human-editable playbook Twin follows on every run, along with the parsed plan steps and the tools each step uses. Read before editing so work produced by a Build run is not overwritten blind.
  • Update Agent Instructions Replaces an agent's instruction document with the supplied content, creating a new version in its history. The content fully overwrites the previous instructions, so they are read first when the intent is to amend rather than replace. Changes take effect on the next run.
  • List Instruction Versions Returns the version history of an agent's instruction document. Each entry carries the full content at that point in time, a content hash and the source that produced it, which is what makes it possible to diff how Twin rewrote the playbook across Build runs or to roll back by feeding an older version into Update Agent Instructions.

Runs

6
  • Start Agent Run Starts a run and returns immediately with the run record while the agent works asynchronously in the cloud browser. Run executes the agent's existing instructions; Build lets Twin explore the target site and write or revise those instructions, at a higher credit cost. The flow polls Get Agent Run or subscribes to On Agent Run Event.
  • Get Agent Run Fetches a single run by ID for polling after Start Agent Run. Twin has no dedicated single run endpoint, so this filters the agent's run list by exact run ID and returns the matching record, or null when the run is not found. The finished flag is the completion signal.
  • List Agent Runs Returns the paginated run history for an agent plus a parallel array of run summaries carrying outcome, human readable title, credits consumed and action count. Filterable by status, start date window or policy group, for example to find every failed run in the last day.
  • List Run Events Returns the ordered event stream for a run: every action the agent took in the browser, with a timestamp and a monotonically increasing event index. A run's extracted output and reasoning live here. After Index tails only what is new since the last read, which keeps polling cheap on long runs.
  • Cancel Agent Run Stops an in progress run. The call is idempotent, so cancelling a run that has already finished still succeeds and any explanatory text comes back in the error field rather than as a failure. Used to bound a run taking too long or heading in the wrong direction.
  • Delete Agent Run Permanently deletes a run and its recorded events from an agent's history. This cannot be undone and is intended for pruning noisy or sensitive runs. Twin returns no body on success, so the action reports the deleted run ID.

Schedules

6
  • Set Agent Schedule Creates or replaces the cron schedule that starts an agent automatically. Each agent has at most one schedule, so calling this again overwrites the previous expression. Twin auto-pauses a schedule after repeated consecutive failures, visible through Get Agent Schedule.
  • Get Agent Schedule Returns the cron schedule attached to an agent, including next scheduled run time, whether it is paused, whether Twin auto-paused it and how many consecutive failures it has accumulated. Returns a null schedule when the agent is not scheduled.
  • Delete Agent Schedule Removes an agent's cron schedule entirely so it no longer starts automatically. Pause Agent Schedule is the alternative when the cron expression should be kept for later.
  • Pause Agent Schedule Pauses an agent's cron schedule without deleting it, so no automatic runs start until it is resumed. Used during a maintenance window on the target site, or while the agent's instructions are being rewritten and reviewed.
  • Resume Agent Schedule Resumes a paused schedule so automatic runs start again on the next cron occurrence. Also the way to restart a schedule Twin auto-paused after repeated failures.
  • List Schedules Returns every cron schedule across all of the account's agents in one call, with each schedule's next run time, paused state and consecutive failure count. The audit of which agents are running unattended and which schedules Twin has auto-paused.

Workspaces

5
  • List Workspaces Returns every workspace in the account with its name, display position and agent count. Workspaces group agents that collaborate and share context, so this is the starting point for organising an account programmatically.
  • Create Workspace Creates a new workspace and returns it with its assigned ID and position. Agents are moved into it with Move Agent To Workspace, or its ID is passed when creating an agent so the agent lands there directly.
  • Update Workspace Renames a workspace and optionally updates its icon configuration. The name is required on every call, so the existing name is supplied when only the icon is changing.
  • Delete Workspace Deletes a workspace from the account. Its agent count is checked with List Workspaces first so what the workspace still contains is known before it is removed.
  • Reorder Workspaces Sets the display order of workspaces in the Twin app by supplying every workspace ID in the desired order. The current IDs are fetched with List Workspaces first, since the array is treated as the complete ordering.

Account

1
  • Get Current User Returns the Twin user the API key belongs to, including the user ID and whether onboarding is outstanding. A lightweight credential check when validating a connection.

Triggers

1 triggers

Event Triggers

1
  • On Agent Run Event Fires when a run of the chosen Twin agent reaches one of the selected lifecycle events. FlowRunner registers a Twin webhook on that agent and removes it when the trigger is deleted. Each delivery carries the run ID, agent ID, run status and, on completion, the outcome, so a flow branches on success, partial or fail without polling. Deliveries are verified against the webhook's HMAC-SHA256 signing secret.

Frequently Asked Questions

What can FlowRunner do with Twin?

FlowRunner agents can run List Agents, Get Agent, and Create Agent in Twin, plus 23 more actions.

Does connecting Twin to FlowRunner require OAuth?

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

Can Twin trigger a FlowRunner workflow automatically?

Yes. Twin supports 1 trigger that can start a FlowRunner workflow automatically.

Start building with Twin

$100 in credits. No card required. Connect in minutes.