Betty Blocks

Betty Blocks is a low-code application platform, and its data API exposes each application's records over GraphQL. Workflows list and read records, describe models, and run raw queries against the app's schema.

Verified 8 actions Session available

Betty Blocks website Platform Documentation Capability data verified 2026-08-25

The nightly reconciliation of a department's intake application begins

List Models reads the application's real query names by introspection, because they are derived from model names and Betty Blocks does not pluralize them

Describe Model returns each field's name and type, which is what decides the filter operators a query is allowed to use

List Records pulls the day's submissions, with the sort and filter expressed the way the API expects rather than as plain JSON

Each record is matched against the system of record downstream and the mismatches are collected

The exception list posts to the operations channel with a link back to the record in the application

A person decides whether a correction goes through the raw GraphQL route at all, or belongs inside a Betty Blocks Action instead

What This Integration Enables

Betty Blocks is where a department's real process often ends up living. Somebody in operations or compliance built the application that tracks the intake, the approvals, the assets, or the cases, and it works, and it is now a system of record that no integration ever reached because its schema belongs to that one application. This connector reads it. List Models returns the query names by GraphQL introspection rather than leaving them to be guessed, Describe Model gives the field names and types that decide which filters are legal, and List Records and Get Record pull the rows out with the sort and filter arguments serialized the way the API actually requires rather than the way a naive encoder would produce them.

What the connector does not pretend is that this is a two way integration. Betty Blocks documents create, update, and delete mutations for every model and then states plainly that mutations run inside a Betty Blocks Action rather than over this HTTP endpoint. That is the product's boundary, not a gap. So the honest shape here is a connector that reads a low code application confidently and treats every write as a decision rather than a call, which is exactly where human-in-the-loop belongs: not as a checkbox on an approval step, but at the point where an agent would otherwise reach through a boundary somebody drew on purpose.

Without FlowRunner

Departmental apps off the map A team builds the application that runs its process, and no integration reaches it because nobody outside the department knows its schema

Schemas guessed from the builder Query and field names are copied out of a screen by hand, and a rename breaks a flow with an error that names nothing useful

Credentials that expire quietly Short lived tokens get pasted into a connection and the integration works until the day it does not

With FlowRunner

The application becomes readable Records are pulled by any flow that needs them, and the department keeps building in the tool it chose

The schema read at run time Model and field names come from introspection on every run, so a flow adapts to a rename instead of breaking on it

Sessions maintained, not stored The connection signs in and refreshes on its own schedule, and a leaked token can be ended immediately

Use Case Scenarios

Reconciling a citizen built intake app against the system of record

A compliance team's Betty Blocks application receives supplier documents and tracks their review. Overnight the agent calls List Models and Describe Model so it is working from the application's current schema, then List Records for everything submitted that day. Each record is matched against the supplier master in PostgreSQL. Records with no match, or with a status the two systems disagree on, are collected into one exception list that posts to Slack in the morning. Nothing in the application is touched by the agent, which is the point: the team that built the app keeps owning what changes in it.
One reporting flow across several applications

An organization runs half a dozen Betty Blocks applications built by different departments. Rather than a flow per application, one flow takes an application identifier and a model name, calls List Models to confirm the query exists, calls Describe Model to build a field selection that matches what is really there, and calls List Records with a filter composed from the field types it just read. The rows land in Google Sheets for the weekly review. When a department renames a field, the flow adapts on the next run instead of failing with a message that means nothing to the person who renamed it.
A lookup that does not need a list

A support agent working a case in Zendesk needs the asset record behind a serial number. The flow calls Get Record with a filter on the external reference rather than the id, because the filter takes any field, and the record's fields come back directly rather than wrapped in a result set. The answer is in the ticket within a second, and the department's application never had to publish a custom endpoint for it.

Human-in-Loop Highlight

Run GraphQL is the only operation on this connector that can attempt a write, and that is not an oversight in the connector, it is the vendor's own line. Betty Blocks publishes create, update, delete, and upsert mutations for every model and then restricts them to Action functions, which run inside the application where the department's own logic, validation, and audit sit. A raw mutation sent over the data API deliberately steps around all of that. Some applications expose one anyway, and an agent that has just introspected the schema is perfectly capable of composing one. So it does not send it. It builds the case and stops: "Reconciliation found 14 supplier records whose review status disagrees with the master. Correcting them here means a raw mutation against the application, outside the Action that normally validates this field. Send it, or open these as tasks for the team that owns the app?" The operations lead answers. Both answers are legitimate, and the difference between them is a judgment about whose process this is, which is not a judgment an agent should be making at three in the morning on its own.

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

Authentication

Login Exchanges an auth profile, username, and password for an access token and a refresh token. Access tokens are short lived and refresh tokens last a matter of weeks, so neither is a credential to paste into a connection and forget. Configuring the profile and credentials instead lets the connector sign in on its own.
Refresh Token Exchanges a refresh token for a new access token. The response carries a new refresh token and the old one is dead, so a flow that stores the original and reuses it works once and then fails in a way that looks like an expiry problem.
Revoke Refresh Token Invalidates a refresh token immediately. The right response to a leaked token, and the only way to end a session before it expires on its own.

Records

List Records Reads records from one of the application's models. The rows arrive wrapped in a result envelope that this connector flattens, and the sort and filter arguments are GraphQL literals rather than JSON, which the connector serializes correctly.
Get Record Reads a single record, whose fields come back directly rather than wrapped. The filter takes any field, not only the id, so a lookup by an external reference works without listing anything.

Schema

List Models Returns the application's models by GraphQL introspection. The operation that makes the rest usable, because query names are derived from model names and Betty Blocks does not pluralize them.
Describe Model Returns a model's fields and their GraphQL types. What to call before writing a field selection or a filter, since a field's type decides which operators it accepts.
Run GraphQL Sends any query or mutation to the application's data API. It is also the only way to attempt a write, which the vendor restricts to Action functions running inside the application, and is why this page's human gate sits here.

Frequently Asked Questions

What can FlowRunner do with Betty Blocks?

FlowRunner agents can run Login, Refresh Token, and Revoke Refresh Token in Betty Blocks, plus 5 more actions.

Does connecting Betty Blocks to FlowRunner require OAuth?

No. Betty Blocks connects to FlowRunner with session-based authentication, no OAuth flow required.

Can Betty Blocks trigger a FlowRunner workflow automatically?

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

Start building with Betty Blocks

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us