Building an Airtable extension: what the SDK really enables

The Airtable extension SDK — heir to the Blocks launched in 2018 — lets you build a full React application that runs directly inside the base. Our thesis: it is the most underrated architectural point of the platform. For a large share of internal tools built on Airtable data, the best custom app for Airtable does not live next to the base. It lives inside it, where the data and the users already are.

The official documentation is explicit about what the object is: custom extensions are React applications, built with function components and hooks, with Node 22 or above as a prerequisite. No proprietary DSL: it is the stack your developers already use, TypeScript included. What the docs called "Airtable blocks development" before the 2022 rename has become a mature application environment.

The trajectory confirms it: Blocks in 2018, Marketplace in 2020, the "Extensions" rename in June 2022 with the stated ambition of covering "any major surface in Airtable", SDK version 1.19.0 in June 2025, and an Interface Extensions SDK in open beta since September 10, 2025. Eight years of continuity: you are investing in a trajectory, not a dead end.

The heart of the SDK is a reactive data model. useBase exposes the schema; useRecords loads the records of a table or view and re-renders the component on every change — the docs promise the extension "will live update as that data changes". No polling to write, no webhooks to wire.

const records = useRecords(view);
// automatic re-render on every change in the base

To keep re-renders under control on large tables, useRecordIds and useRecordById offer finer granularity; useLoadable and useWatchable give manual control over loading and subscriptions. The Cursor model exposes the user's interaction state — activeTableId, activeViewId, selectedRecordIds — and drives navigation via setActiveTable(). Concretely: the extension knows what the user is selecting in the grid and can react to it.

GlobalConfig completes the model: a persistent key-value store, synchronized in real time across all connected users, with optimistic writes via setAsync. Its ceilings are public — 150 kB and 1,000 keys per installation. Plenty for configuration; beyond that, the pattern to remember is to store application state in the tables themselves.

On the interface side, the component library aligns with the native UI: CellRenderer displays a cell exactly like the grid, TablePickerSynced binds a table picker to GlobalConfig, and one utility brings you back to Airtable's interface at any moment:

expandRecord(record); // opens the native record view, without leaving the extension

The extension also writes to the base — create, update, delete in batches of 50 records per call — with explicit checks before acting: checkPermissionsForUpdateRecord returns hasPermission plus a message you can display to the user.

Three classic costs of an internal application disappear because the app lives inside the base.

Hosting, first. On block release, the code is bundled and sent to Airtable's servers, which host it — "we host the released bundles for you": zero servers, zero pipeline to maintain.

Authentication, next. The official FAQ puts it plainly: a custom extension automatically enforces the existing permissions of the collaborator using it. It inherits their rights, runs in a sandboxed iframe and only accesses the data of the base it is installed in. No SSO to integrate, no auth layer to write or audit.

Synchronization, finally. The reactive model keeps on-screen data always current, with no webhook queue and no sync job. What other architectures pay for in infrastructure, the SDK gives you by position — an argument that connects to the seat math: the Airtable seats are already paid for, the extension makes them earn their keep.

What doing nothing costs — Building the same internal tool outside the base means buying back what the SDK gives you: hosting to operate (versus 0 servers after block release), an authentication layer to write and then audit (versus automatically inherited permissions), synchronization to wire (versus native live updates) — and a second interface to drive adoption for, while the base's seats are already paid for and open every day.

We built 17 custom Airtable extensions in one year, in React and Tailwind, directly inside the bases. The most complete is a CRM: Aircall telephony, templated emails, SMS and WhatsApp, interactive maps, activity tracking. It was adopted immediately — the team did not switch tools, the tool came to them.

That spectrum demonstrates three capabilities a quick read of the docs cannot measure. Rich UI: interactive maps and complete CRM views fit inside the iframe. Outbound network calls: telephony, SMS and emails go out from the client, from the extension — the docs publish no network quota for these calls; we simply observe that they run in production. Well-distributed state: configuration in GlobalConfig, business data in the tables.

The development cycle is short, tooled by the official @airtable/blocks-cli (v2.0.4 as of August 12, 2026):

To distribute beyond a single base, two documented routes: Marketplace submission, with a functionality and security review, or "remixable" open-source publication from GitHub.

The SDK is a strength of the platform, not a universal answer. We also ship external applications — 8 Next.js, Supabase and Vercel apps in production — when the need justifies it. The scoping fits in one table.

The dividing line is positional. If the users and the data are already in the base, the extension wins. If the users are outside — clients, candidates, partners — the seat math flips and the external application takes over.

Extensions are a paid-plan feature, and a custom extension remains specific to its base outside the Marketplace: sharing across bases requires block add-remote and one release per target. On very large bases, Airtable may pause extensions at load time to protect performance. The ceilings — 50 records per call, 150 kB of GlobalConfig — are comfortable for an internal tool, but point toward a backend as soon as volumes or processing grow. The Interface Extensions SDK, in beta since September 2025, starts with single-table access and a smaller component library. Finally, our own track record is one year and 17 extensions: significant, not exhaustive.