Glide

Read and write the data behind your Glide apps through the Glide Tables API. Agents add, update, and fetch rows in Big Tables, inspect and create table schemas, and sync records from CRMs, stores, and forms into a no-code app.

8 actions API key available

Glide website ↗ Platform Documentation ↗ Capability data verified 2026-07-27

A new order lands in the storefront

Get Table Schema confirms the fulfillment table's column keys before any write

Add Rows appends the order into the Big Table that powers the warehouse team's Glide app

Rows that fail schema validation are held rather than written with silently dropped fields

Update Row marks the source record as synced once the write confirms

The daily digest posts unfulfilled counts from Get Rows to the operations channel

When a cleanup sweep proposes deleting stale rows, an operator confirms the list before Delete Row runs

What This Integration Enables

A Glide app is only as good as the table behind it, and that table is where no-code projects quietly die: the app looks finished, but keeping its data current is a manual job nobody signed up for. This connector makes the data layer an agent's responsibility. FlowRunner agents read and write rows in Big Tables, inspect schemas so writes match the columns that actually exist, create new tables with seed data on demand, and keep older apps alive through the legacy mutate endpoint. - Sync records from CRMs, stores, and forms into the Big Tables that power your apps - Add, update, and delete rows in response to external events - Read rows out for reporting, notifications, and downstream systems - Discover table IDs and inspect column schemas before any write - Create new Big Tables with defined columns and optional seed rows - Maintain legacy apps through Mutate Tables (Legacy) batch operations The one operation in this set that cannot be walked back is row deletion, and that is exactly where FlowRunner's [human-in-the-loop](/concepts/human-in-the-loop) gate sits.

Without FlowRunner

The app's data is fed by hand Someone re-keys orders, requests, and updates into the table behind the Glide app, or the app runs stale

Schema drift breaks writes silently A renamed column means imports drop fields without anyone noticing until the app shows blanks

The app is an island Data flows in but nothing flows out, so reporting means exporting the table again

With FlowRunner

External events write themselves in Orders, form submissions, and CRM changes append and update rows the moment they happen

Writes are schema-checked first Agents read the table schema before writing, and mismatches surface instead of vanishing

The app feeds the rest of the stack Get Rows pulls app data into reports, notifications, and downstream systems on a schedule

Use Case Scenarios

The fulfillment app that stays current by itself

Every new [Shopify](/integrations/shopify) order triggers Add Rows into the Big Table behind the warehouse team's Glide app, with column keys verified against Get Table Schema at the start of each run. Pickers see new orders on their phones without anyone importing anything, and Update Row flips the status column as each order moves, so the storefront and the floor agree.

Spreadsheet to app, with a receipt for every row

A migration agent pages through [Google Sheets](/integrations/google-sheets) with Get Rows on the source side, batches records into Add Rows, and writes each returned row ID back to the source sheet as a sync receipt. Rows that fail schema validation queue for review instead of landing malformed. The team gets a Glide app fed from the spreadsheet they already trust, and every row can be traced both directions.

The daily read that replaces the export

Each morning the agent calls Get Rows against the requests table, filters for items past their SLA, and posts the summary to [Slack](/integrations/slack) with counts and the oldest offenders named. Weekly, the same data lands in the reporting warehouse. The Glide app stops being a place data goes to be looked at and becomes a source other systems read from.

Human-in-Loop Highlight

Delete Row removes a row from a Big Table permanently, and because that table is the live backing store of a running app, the deletion propagates to every screen instantly: the record does not archive, it vanishes from the tool a team is working in. So cleanup agents here never delete on pattern-matching alone. A stale-record sweep gathers candidates with Get Rows, posts the list with row contents and age attached, "27 request rows closed more than 180 days ago, full contents in the attached digest, remove?", and waits for the app's owner to answer. The same discipline covers Mutate Tables (Legacy), whose batch format can carry delete-row mutations for older apps; any batch containing one is surfaced for approval before it posts. Adding and updating run at machine speed because they are correctable. Vanishing is not.

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

8 actions

Rows

Add Rows Adds one or more rows to a Big Table, keyed by column names or IDs from the schema, returning generated row IDs in input order. Schema Error Handling controls what happens when a key does not match.
Update Row Sets column values on an existing row. Only supplied columns change; omitted columns stay untouched, which makes it safe for partial status updates.
Delete Row Permanently deletes a single row by its row ID. Cannot be undone; the operation this page's human gate exists for.
Get Rows Retrieves rows with an optional limit and a startAt cursor for paging large tables. Each row returns its $rowID alongside column values, which is what later updates and deletes key on.

Tables

List Tables Lists the Big Tables available to the API token with each table's ID and name. The discovery step before any row operation.
Get Table Schema Retrieves a table's columns with names, IDs, and data types. Read before writing so Add Rows and Update Row use the exact keys the table expects.
Create Table Creates a new Big Table with a name and column schema, optionally seeded with initial rows. Returns the new table ID and seeded row IDs. Useful for provisioning app backends on the fly.

Legacy

Mutate Tables (Legacy) Runs a batch of mutations against a Glide app's tables through the legacy v1 endpoint: adding rows, setting columns, and deleting rows in one call, keyed by app ID and legacy table names. For older apps only; new work uses the v2 operations above.

Frequently Asked Questions

What can FlowRunner do with Glide?

FlowRunner agents can run Add Rows, Update Row, and Delete Row in Glide, plus 5 more actions.

Does connecting Glide to FlowRunner require OAuth?

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

Can Glide trigger a FlowRunner workflow automatically?

Glide doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Glide

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

Start Building Free Talk to us