Skip to content
TablePage.ai Open the app

Airtable Embeds Remain Available After the Acquisition

Audit Airtable view and base embeds for scope, access, regenerated links, mobile behavior and fallback exports following the Bending Spoons deal.

Share X in f
Wei Hu

Airtable embeds remain available after the Bending Spoons acquisition, so working iframe code does not need to be replaced solely because ownership changed. Bending Spoons completed its acquisition of Airtable on September 4, 2026. The announcement promised investment in the product, customer support and go-to-market capabilities but did not announce changes to embeds or shared views (Airtable).

As of September 30, 2026, Airtable’s documentation lists embedding for all plan types. An embed places a live, read-only copy of a view or base inside a webpage that accepts third-party iframes (Airtable Help Center). The practical response to the acquisition is to audit each publication, verify its scope and preserve a fallback—not to migrate automatically.

Set the three audit results; the tool shows whether an embed is ready to keep.

Airtable Embed Readiness Check

Classify the source, reader test and fallback for one published embed.

Checks to make before selecting “Yes”
  • For scope, inspect hidden and special-purpose fields and decide whether a view or the entire base is intended for publication.
  • For access, test the published webpage under the reader’s expected logged-out, account or password conditions.
  • For the fallback, validate the source, extraction date, field definitions, row counts, column names, identifiers and date formats.
  • If a share link was regenerated, replace and test every published iframe that used the old code.

Source: Airtable embedding documentation and Airtable view sharing documentation.

Audit Each Embed From Source to Webpage

Create one audit record for every published Airtable iframe. The record should identify both the webpage where the iframe appears and the Airtable source behind it.

Field Example Value Why It Matters
Page URL /research/project-list Locates the published iframe
Airtable base and view Projects / Public projects Identifies the source
Scope View Distinguishes a curated view from a whole base
Data owner Research desk Assigns responsibility
Access restriction None Records who can open it
Bulk copying allowed No Documents the current setting
Last checked 2026-09-30 Shows whether the audit is current
Replacement needed No Creates an actionable queue

Then test the complete path from the Airtable source to the published page:

  1. Open the source base and select the intended view.
  2. Choose Share and sync, then Embed this view.
  3. Compare Airtable’s preview with the published page. Replace the iframe code only if the existing instance is outdated or broken.
  4. Test the page as its intended reader. For an unrestricted public view, use a logged-out window. For a restricted view, use an account or password that should have access.
  5. Confirm that the expected rows and fields appear and that the surrounding page remains usable on a narrow screen.

Those menu labels reflect Airtable’s current embed instructions (Airtable Help Center). If the Airtable preview works but the published page does not, check whether the website platform accepts third-party iframes before treating the failure as an Airtable outage.

The audit should cover every place where the iframe has been copied. Testing only the Airtable preview does not establish that each published instance works, particularly when different sites or page builders handle third-party iframes differently.

Prefer a View Embed When the Whole Base Should Not Be Public

A view provides a narrower publication surface than a base. Its record filters, hidden fields, groups and sorts are reflected in the embed, allowing the published version to differ from the working base.

Hidden fields are normally omitted, but that is not absolute. Fields used for grouping, calendar dates, gallery or kanban covers, and kanban stacks can remain visible. The Show all fields in expanded records setting can also reveal fields that otherwise appear hidden (Airtable Help Center). Review expanded records as well as the default grid or card display.

A whole-base embed is broader. Airtable says it exposes all information in the base, including information added after the embed is published (Airtable Help Center). Use a base embed only when the entire base is intended for publication now and as it changes.

Do not treat a randomized share URL, a hidden field or a disabled download button as a privacy boundary. Anyone with an unrestricted link can access the shared content. Turning off Allow viewers to copy data out of this view prevents bulk copy operations and CSV downloads, but it cannot prevent someone from copying an individual visible cell (Airtable Help Center). Sensitive information should not be placed in a publicly shared base or view.

Scope should therefore be checked at the source rather than inferred from the appearance of the embedded page. Confirm the source view, inspect special-purpose fields that may remain visible and open an expanded record before approving publication.

Treat a Regenerated Link as a Deployment Change

Choosing Generate new link invalidates the previous shared-view URL. After regenerating a view or base share link, Airtable requires you to copy the updated iframe code and replace every published instance that uses the old code (Airtable Help Center).

Handle regeneration as a small release:

  1. Find every page containing the old iframe.
  2. Generate the replacement link.
  3. Replace all affected iframe snippets.
  4. Test each page under its intended access conditions.
  5. Record the new check date in the audit table.

Do not assume that updating one page updates another copy of the iframe. Each published snippet must be found and replaced.

Disabling a view link is different from generating a new one. If you disable and later re-enable a view link, Airtable says the same URL is preserved unless you choose Generate new link (Airtable Help Center). Record which action was taken before deciding whether a deployment is required.

Preserve a Reviewed Fallback Dataset

For consequential public data, keep a reviewed CSV or spreadsheet snapshot outside the embed. Record its source, extraction date and field definitions. Validate its row counts, column names, identifiers and date formats so it can be published independently if the live embed no longer meets the project’s requirements.

Take care when creating that snapshot from a shared view. Filters applied by a visitor do not affect Airtable’s CSV download. The downloaded file contains records from the original shared view, not the temporary filter applied in the visitor’s browser (Airtable Help Center).

Create or select the intended source view before exporting. Then compare the resulting file with that source rather than assuming the browser’s temporary display controls determined the export.

A fallback file does not require replacing a working embed. It provides a reviewed copy with known fields and a recorded extraction date, ready to support a standalone public data page if product behavior, policy or publishing requirements change.

Keep the Embed When the Audit Passes

A working Airtable embed can remain in place when its source scope is appropriate, its access behavior has been tested as the intended reader and its published fields match what should be public. A whole-base embed deserves additional scrutiny because later additions to the base are also exposed.

Replace iframe code when it is outdated, broken or tied to a regenerated link—not merely because the acquisition occurred. Maintain the audit record, retest the published page after relevant source or access changes, and keep the reviewed fallback dataset separate from the live iframe.