How to Keep an Airtable Table in Sync with Your WordPress Site

Updated July 2026 • 6 min read • By Fahad Murtaza

TableCrafter fetches Airtable data live on each page load and supports an auto-refresh interval so your WordPress table stays current without any webhooks or scheduled WordPress cron jobs. This guide explains exactly how the sync mechanism works, what triggers a re-fetch, how the caching layer behaves, and how to force a manual resync when you need data updated immediately. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native. Notion reached 30 million registered users in 2023 (Notion, 2023).

What Is the Core Sync Model: Fetch on Demand?

TableCrafter does not store a copy of your Airtable data in the WordPress database. Every time a visitor loads a page containing a TableCrafter shortcode, the plugin sends a request to the Airtable REST API and renders the response. This means:

• Data is always current as of the last fetch
• No database tables to maintain or migrate
• No import step required when records change in Airtable
• API rate limits apply (Airtable allows 5 requests per second per base)

For most WordPress sites, a single page load triggers one API call to Airtable per table shortcode on that page. If you have three Airtable-sourced tables on the same page, that is three API calls on page load.

This step completes the connection between your data source and the TableCrafter table engine. Once saved, the plugin caches the connection credentials in the WordPress options table and uses them on every subsequent page load. If you update the source configuration later - for example, rotating an API key or changing a sheet URL - return to this step, enter the new value, and save again. The table updates immediately on next load without any shortcode changes.

What Is SWR Caching: Stale-While-Revalidate?

To avoid hammering the Airtable API on every page view across all visitors, TableCrafter implements a stale-while-revalidate (SWR) caching layer using the WordPress transient system.

Here is how it works:

1. The first visitor to load the page triggers a live fetch from Airtable. The response is stored as a WordPress transient under the key gt_airtable_table_{table_id} with a configurable TTL (time-to-live).
2. The next visitor within the TTL window receives the cached response instantly. No Airtable API call is made.
3. Once the transient TTL has elapsed, the next visitor to load the page triggers a new live fetch from Airtable. The transient is then rebuilt for the next TTL window. There is no background refresh scheduling; the mechanism is a simple lazy cache that refreshes on-demand when expired.

The default interval is 30 minutes. This means data displayed to visitors is at most 30 minutes behind what is in Airtable. The interval can be configured between a minimum of 5 minutes and a maximum of 24 hours. Values outside this range are automatically clamped to the nearest boundary.

How Do I Configure the Cache TTL?

To change the cache TTL for a specific Airtable table:

If this step produces unexpected output, check the source data directly in the connected system. TableCrafter passes data through without modification - if a cell displays an unexpected value, the source record contains that value. Use the TableCrafter debug log (Settings > Advanced > Debug Mode) to trace the exact query sent to the source and the raw response received, which narrows the diagnosis to either a source-side or rendering-side issue.

1. Go to TableCrafter → Manage Tables and open the table configuration.
2. In the Data Source section, find the Cache Duration field.
3. Enter the number of minutes. Common values:
   • 5, 5 minutes (minimum allowed; for data that changes very frequently)
   • 30, 30 minutes (default; good for most editorial and operational use cases)
   • 60, 1 hour (for slow-changing data like event lists or contact directories)
   • 1440, 24 hours (maximum allowed; for very static data like a published content calendar)
4. Save the table configuration.

What Is Auto-Refresh Interval: Keeping the Page Live?

The auto-refresh interval is a client-side feature. When enabled, TableCrafter injects a JavaScript timer that re-fetches and re-renders the table at a set interval without the visitor needing to reload the page. This is useful for dashboards, live scoreboards, inventory displays, or any scenario where visitors keep the page open and need to see updates appear automatically.

To enable auto-refresh:

1. In the table configuration, find Auto-Refresh and enable it.
2. Set the interval in seconds via the refresh_interval setting. A minimum of 5 seconds (5000 ms) is enforced. Common values are 30 seconds, 60 seconds, or 120 seconds.
3. Leave auto-refresh disabled (default) for tables where static or cache-served data is sufficient.

You can also enable auto-refresh at the shortcode level:

[tablecrafter id="1" auto_refresh="true" refresh_interval="30000"]

The refresh_interval value is in milliseconds. The shortcode parameter overrides the table configuration setting. This lets you use the same table on multiple pages with different refresh rates, for example, a 30-second interval on a live dashboard and no auto-refresh on a static archive page.

What Triggers a Re-Fetch from Airtable?

A fresh request to the Airtable API is made in these situations:

The shortcode accepts all column and filter settings defined in the table builder as defaults, but you can override individual parameters inline. For example, `[tablecrafter id="1" per_page="25"]` overrides the default rows-per-page setting for this specific embed without changing the saved table configuration. This lets you reuse one table definition across multiple pages with different display requirements.

• A visitor loads the page and the transient cache has expired
• The auto-refresh interval fires on the client side
• A visitor applies a filter or changes the sort order (when server-side filtering is enabled)
• A visitor edits a record inline (the write is sent to Airtable and the cache is invalidated)
• You manually clear the cache from the TableCrafter admin (see below)
• A WordPress plugin flushes all transients (for example, some caching plugins do this on settings save)

How Does Forcing a Manual Resync Work?

TableCrafter's Airtable cache refreshes lazily: changes you make in Airtable are picked up automatically when the transient expires and the next page load triggers a new fetch. For most editorial workflows this is sufficient. When you need changes to appear immediately before the configured interval elapses - for example, you just corrected a pricing error in Airtable and need the WordPress page updated within seconds - you have three methods available. Each method deletes the WordPress transient so the next page load is forced to fetch live data from the Airtable API.

Method 1: Clear from TableCrafter Admin

This is the recommended method for most users and covers the majority of cases where an immediate data refresh is needed. The Clear Cache action deletes only the WordPress transient for that specific table, leaving all other table caches and site transients intact. It does not affect any other plugin or WordPress setting, and it does not modify the table configuration or the Airtable API connection credentials. After the transient is deleted, the next visitor to load a page containing that table triggers a live fetch from Airtable, which also rebuilds the transient for the next configured interval. On high-traffic pages, the first post-clear page load may be slightly slower than usual while the plugin waits for the Airtable API response before rendering.

1. Go to TableCrafter → Manage Tables.
2. Hover over the table row and click Clear Cache.
3. The next page load fetches fresh data from Airtable and rebuilds the transient.

Method 2: Use the WP-CLI Command

WP-CLI provides programmatic transient management useful in deployment scripts, post-import hooks, or automated workflows where you need to force a cache clear without logging into the WordPress admin. Each Airtable table has its own transient stored under the key gt_airtable_table_{table_id}, where {table_id} is the numeric ID shown in the table's edit URL in the TableCrafter admin (for example, a URL ending in ?id=3 means the table ID is 3). Delete a specific table's transient by passing its full key. After deletion, the next page load for that table fetches live data from Airtable and rebuilds the transient. This method requires SSH access and WP-CLI installed on the server.

wp transient delete gt_airtable_table_3

Replace 3 with the numeric ID of the table to clear. Run wp transient list --search="gt_airtable_table_*" to see all current Airtable transients on the site.

Method 3: Use Your Caching Plugin's Flush

If your site uses a WordPress page caching plugin such as WP Rocket, LiteSpeed Cache, or WP Super Cache, purging the page cache for a specific URL forces that page to regenerate on the next request. During regeneration, if the TableCrafter transient for the Airtable table has already expired, the plugin re-fetches live data from Airtable before rendering the HTML. If the transient has not yet expired, the regenerated HTML still contains the cached Airtable data, even though the page cache was cleared. For this method to guarantee fresh Airtable data, either combine it with the admin cache clear (Method 1) first, or set the TableCrafter cache interval shorter than your page cache TTL. This method is most convenient during content deployments where you are already flushing the full-site page cache, because no extra steps are needed for tables on those pages.

How Do Inline Edits and Cache Invalidation Work?

When a visitor edits a record inline and TableCrafter writes the change back to Airtable via the API, TableCrafter automatically invalidates the WordPress transient cache for that table. This ensures the next page load (by the same visitor or any other) reflects the edit rather than serving stale cached data that would appear to overwrite the just-made change.

The cache invalidation is selective: only the transient for the specific table and data source combination is cleared, not all TableCrafter transients on the site. Other tables connected to the same Airtable base continue to serve their cached data unaffected until their own TTL expires or their cache is separately invalidated. The invalidated table re-fetches from the Airtable API on the next page load and rebuilds its transient at the configured TTL interval.

If a visitor edits a row and then immediately reloads the page, there is a brief moment (typically under 2 seconds) where the table re-fetches live from Airtable. During that fetch, if the table has pagination enabled, the page count may briefly show "Loading" until the fresh dataset is cached. This is expected behavior and does not indicate a data loss condition - the edit was confirmed before the cache was cleared, so the Airtable record already contains the updated value.

How Does No Webhooks Required Work?

Some Airtable integrations rely on Airtable webhooks to push data changes to an external system. TableCrafter does not require webhooks. Since data is fetched on demand, changes made in Airtable are automatically picked up on the next cache-expired fetch. This simplifies setup considerably, there is no webhook endpoint to configure, no HTTPS requirement beyond standard WordPress, and no risk of webhook delivery failures causing stale data indefinitely.

This configuration interacts with any caching or CDN layer active on your WordPress installation. If you use WP Rocket, LiteSpeed Cache, or a CDN such as Cloudflare, flush the page cache after making this change to ensure the updated configuration is reflected in the cached HTML served to visitors. TableCrafter's server-side output is regenerated on the next uncached request.

How Do Pagination and Large Datasets Work?

Airtable's API returns up to 100 records per request. For tables with more than 100 records, TableCrafter automatically handles pagination by following Airtable's offset tokens, making sequential API calls (100 records each) until all records are fetched. The full dataset is assembled in memory and stored as a single WordPress transient. This means the initial page load for large tables triggers multiple sequential API calls - a table with 500 records requires 5 API calls before the first response is cached. Subsequent loads within the TTL window are served from the WordPress transient at full speed with zero API calls.

For very large Airtable bases (1,000+ records), consider whether all records are needed for display or whether a filtered view in Airtable would reduce the fetch volume. Airtable's API allows specifying a view name in the data source configuration - TableCrafter fetches only the records visible in that view, not the full table. A view filtered to "Active Members Only" with 200 records fetches in 2 API calls instead of 10, halving the initial cache-build time. For tables exceeding 5,000 records, contact TableCrafter support about server-side cursor pagination, which renders only the current page rather than fetching the entire dataset at once.