Documentation Index

Fetch the complete documentation index at: https://support.airtable.com/llms.txt

Use this file to discover all available pages before exploring further.

Creating custom extensions with Airtable Blocks SDK

  • Updated on Jul 24, 2026
  • Published on Jul 7, 2022
  • 2 minute(s) read
Prev Next

Plan availability

All plan types

Permissions

Owner or Creator permissions are required to perform the actions outlined in this article

Platform(s)

Web/Browser, Mac app, and Windows app

Creating custom extensions overview

Use the Airtable SDK to create real-time, interactive extensions that live in Airtable. You can create your extension in your own development environment and import your npm packages.

Creating custom extensions

  1. Open your Airtable home screen.

  2. Create or open the base where you want to install the contact import extension.

  3. Click Tools in the upper-right corner.

  4. Click the Extensions option.

  5. Click Add an extension.  

  6. Click + Build a custom extension.

Deploying your custom extension

After you build a custom extension locally using the Blocks CLI, you publish it to your base using the block release command from the Blocks CLI. This uploads your bundled code directly to Airtable, which hosts and serves it — you don't need a separate hosting provider.

Note

Airtable doesn't support deploying custom extensions through GitHub, GitHub Actions, or other CI/CD pipelines. The supported path is local development with the Blocks CLI, followed by running block release to publish your build. If you want repeatable releases, you can still call the Blocks CLI from your own scripts or terminal — Airtable just doesn't provide a native GitHub/CI integration for this step.

FAQs

Why did my custom extension fail on block release with "The bundle's size is too big" / s3ApiBundleTooLarge error?

Custom extensions have a maximum bundle size of 10 MB when you upload via block release. If your bundle exceeds that, the release fails with s3ApiBundleTooLarge. This limit is fixed and can't be increased. The most common cause of an oversized bundle is including a large library directly in the bundle (3D engines, charting libraries, etc.). To get under the limit:

  • Load large libraries from a CDN at runtime instead of bundling them. Using a script tag or a dynamic import() to pull a library (for example, from jsDelivr, unpkg, or your own hosted location) keeps it out of your bundle entirely — this is usually the single most impactful change.

  • Import only what you need (tree-shaking). If the library ships modular ES6 packages, import only the specific modules/classes you use rather than the whole library, so unused code isn't bundled.

  • Audit your bundle. Use a tool like webpack-bundle-analyzer or source-map-explorer to find the largest dependencies and decide what to trim or externalize.

  • Externalize large static assets. Host big assets externally and load them at runtime rather than bundling them.

Keep in mind that you can  oad a third-party library (3D engine, etc) from a CDN in a custom extension instead of bundling it — it's the recommended way to stay under the 10 MB bundle limit for heavy libraries. Load the library at runtime from a CDN (a public CDN such as jsDelivr/unpkg, or your own hosted location) rather than including it in your release bundle. Developers have, for example, hosted a library via GitHub Pages and loaded it at runtime to bring a large extension well under the limit. Combine CDN loading with tree-shakeable imports of only the modules you use for the smallest possible bundle. Keep in mind runtime-loaded resources depend on the external host being reachable, so use a reliable CDN/host.