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 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. In the background, TableCrafter checks whether the cached data is older than the revalidation threshold. If it is, it schedules a background refresh so the next page load receives fresh data.

The default TTL is 60 seconds. This means data displayed to visitors is at most 60 seconds behind what is in Airtable. You can adjust this in TableCrafter's source settings.

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 seconds. Common values:
   • 60, 1 minute (default, good for most use cases)
   • 300, 5 minutes (good for slow-changing data like event lists)
   • 3600, 1 hour (for very static data like a published content calendar)
   • 0, no cache (real-time, use with caution)
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 Interval.
2. Enter the interval in seconds. A value of 30 refreshes the table every 30 seconds.
3. Leave the field blank or set it to 0 to disable auto-refresh (default).

You can also set the auto-refresh interval at the shortcode level:

[tablecrafter id="1" refresh="30"]

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 fast refresh on a live dashboard page and no 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?

If you update records in Airtable and need the WordPress table to reflect the changes before the cache TTL expires:

Method 1: Clear from TableCrafter Admin

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

Method 2: Use the WP-CLI Command

If you have WP-CLI access to your server:

wp transient delete --network tablecrafter_airtable_*

This deletes all TableCrafter Airtable transients site-wide. The next request to any Airtable-sourced table fetches fresh data.

Method 3: Use Your Caching Plugin's Flush

If you run a WordPress caching plugin like WP Rocket or WP Super Cache, purging the page cache also effectively forces a fresh fetch on the next page load, since the cached page HTML is regenerated and TableCrafter re-fetches from Airtable during that generation.

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.