Integrations

An integration is an external service connected to a workspace. You connect it once, and then any app, block, or workflow in that workspace can use it. Most of the ones you will browse here hold data — an Airtable base, a Google Sheet, a Notion database, a monday.com board, a Supabase project — and those are the workspace’s data sources.

These six tools let an assistant explore what’s connected, find the exact table it needs, and look at a few of its real records. They are all read-only. They exist to answer “what data is available here, and what does it look like?” so the answer can be used somewhere else: wiring a table to a vibe coding block, or filling in a workflow step that reads from Airtable.

Browsing is a drill-down

These tools are one path, not six separate features. Each level needs an ID from the level above, so the assistant walks down from the workspace to the fields of one table, and then to a sample of its records.

integration_list                          workspace
└── integration_list_databases             a base, spreadsheet, doc, workspace, or database
    └── integration_list_schemas           only some integrations have this level
        └── integration_list_tables        a table, sheet, board, or list
            ├── integration_list_table_fields   its fields
            └── integration_get_sample_records  a few of its real records

Some integrations have a middle level

Most go straight from the top level to tables. Seven have something in between, so browsing them takes five steps instead of four:

A SQL connection usually has just one database — for Supabase it is called postgres.

For everything else, skip integration_list_schemas and go straight from databases to tables. Calling it on an integration that has no middle level returns an error rather than an empty list, so that “no schemas” is never mistaken for a fact about your data.

Which integrations are supported

Every data source type Softr supports can be browsed and connected to a block through MCP:

Each has its own setup guide in the Data Sources section of these docs. Connect it to the workspace there first, and it becomes browsable through MCP.

Referencing fields in code

integration_list_table_fields returns each field’s type and options, the table’s primary field, and one thing that matters more than it looks: how fields must be referenced in code.

Rather than memorising that table, read fieldReferenceKey from the response: it says "id" or "name" for the table you just looked at. For SQL databases the two are the same string anyway, because a column’s ID is its name.

Reading real values before building

A field list says a column is called Status and holds text. It does not say whether the values are open and sold or Open and Sold, which roles your users table actually contains, how dates are written in a sheet, or which tab of a spreadsheet holds the data. An assistant that builds without knowing produces an app that saves "Sold" into a source that only accepts "sold", or user groups for roles nobody has.

integration_get_sample_records closes that gap. Given the same IDs as integration_list_table_fields plus the app being built, it returns:

The assistant can pass fields to read only some columns and limit to read more rows — the usual way to learn all the options of a status column is to ask for that one field with a higher limit.

Two things to know about how it reads:

• It reads through an app. The tool takes an application ID because Softr reads external data on behalf of an app, not of a workspace. For a vibe coding app that is the app being built; create it first. The same read is what the app will use once the table is connected, so nothing is done twice.
• The first read of a new table may need a retry. For Airtable, Google Sheets, Notion and the other synced sources, the first time any Softr app reads a table Softr starts syncing it. A small table finishes within the call; a large one may not, and the tool answers with a conflict asking the assistant to retry in about ten seconds. SQL sources such as Supabase are read live and do not have this step.

The sample is available with Applications & Forms: Read only access to the app’s workspace, plus the integration being connected to that workspace. It supports every integration in the table above except Softr Databases, which have their own record tools.