Formsite
FormsRead Formsite form data into your workflows. Agents list forms, inspect form items, and retrieve results individually or in bulk for processing downstream.
What This Integration Enables
Formsite is where the submissions live, and submissions that sit in a results table are decisions nobody has made yet. FlowRunner treats a Formsite account as a data source that agents read on a discipline: List Forms to discover what exists, Get Form Items to learn each form's structure, and List Results with After ID to pull only what arrived since the last sweep. That last part matters more than it sounds. Incremental reads keyed on a cursor are what separate a reliable sync from a nightly batch job that either re-imports everything or quietly misses a page. And because Formsite forms carry typed items, choice fields, dates, file uploads, an agent that reads the item structure first can route a submission by what it contains, not just log that it exists. - Route registrations, orders, and survey responses into CRMs, spreadsheets, and messaging tools within minutes of submission - Verify a form's field structure before every load, so a form edit becomes a paused workflow instead of a corrupted dataset - Look up a single submission with Get Result when a downstream record needs its source context - Keep humans on the exceptions: failed loads, changed forms, and ambiguous entries, not the routine ninety percent - Run the same discipline across every form in the account, since List Forms makes new forms discoverable without a workflow edit
Without FlowRunner
With FlowRunner
Use Case Scenarios
The lead form that feeds the CRM before the coffee is cold
A demand gen team runs event registration through Formsite. Every fifteen minutes an agent calls List Results with After ID set to the last processed submission, maps each answer through the item ids from Get Form Items, and upserts the respondent into [HubSpot](/integrations/hubspot) as a contact with the event and session preferences attached. A row lands in [Google Sheets](/integrations/google-sheets) for the reporting view, and a Slack message tells the field marketer who just registered. Nobody exports anything, and the cursor guarantees nobody gets imported twice.
The form edit that did not corrupt the pipeline
A product feedback form gets a new question inserted in the middle, which shifts the item positions below it. On the next sweep, the agent's Get Form Items call returns a structure that no longer matches the saved mapping. Instead of loading answers into the wrong CRM fields, the workflow holds the batch, posts the old and new field lists side by side to the ops channel, and waits. A person confirms the new mapping in one message, and the held submissions load correctly into the right fields. The alternative, discovered three weeks later in a segmentation report, is the reason this check exists.
One submission, pulled on demand
A support agent working a ticket needs the original intake form a customer filled out. The workflow takes the result id stored on the CRM record, calls Get Result, and posts the full submission, timestamps, status, and every answered item into the ticket thread. The context arrives in seconds, keyed to the exact submission rather than a search across a results table, and the ticket thread now carries a permanent record of what was actually asked for.
Human-in-Loop Highlight
List Results with After ID is the engine of every incremental sync on this page, and the cursor it advances is the risk. Once the workflow records a new high-water mark, the submissions behind it will never be fetched by the incremental pull again. If forty results came back but only thirty-seven CRM writes succeeded, advancing the cursor anyway means three respondents silently vanish from the pipeline, and no error will ever surface them. So the agent reconciles counts on every sweep, and when they disagree it does not advance. It posts the three unprocessed result ids with their failure reasons and asks a person to retry, remap, or consciously skip. Fetching data is reversible. Moving the cursor past data you did not process is not.
Agent Capabilities
4 actionsForms
2- List Forms Lists all forms in your Formsite account, returning each form's directory identifier, name, public link, state, and result counts. The directory value is what every other operation takes as input, so this is where discovery starts.
- Get Form Items Retrieves the fields defined on a form, including each item's numeric id, position, label, and type. Item ids map to the columns in results, which makes this the integrity check that runs before any submission data is trusted downstream.
Results
2- List Results Lists submissions for a form with pagination, filtering, and search. After ID and Before Date make incremental syncs practical: each sweep fetches only what is new, up to 100 results per page.
- Get Result Retrieves a single submission by its result id, with timestamps, status, and every answered item. The on-demand lookup for enriching a record or answering "what exactly did they submit."
Frequently Asked Questions
What can FlowRunner do with Formsite?
FlowRunner agents can run List Forms, Get Form Items, and List Results in Formsite, plus 1 more action.
Does connecting Formsite to FlowRunner require OAuth?
No. Formsite connects to FlowRunner with an API key, no OAuth flow required.
Can Formsite trigger a FlowRunner workflow automatically?
Formsite doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Formsite
$100 in credits. No card required. Connect in minutes.