Connecting Airtable to Make is never just clicking connect
If you’ve already tried this, you know what’s coming. I dropped my Airtable API key into Make and got a beautiful green checkmark. You’d think it would just work. It didn’t. :/
First issue: Airtable changed how new workspaces handle API access. My automations were erroring out because the base I was using didn’t grant access to the key I had stored. It looked fine on the Make side—until you tried to pull any records. Just…nothing. Zero rows. No warnings.
To fix it, I had to:
1. Go back into Airtable, find the actual base shared with the automation workspace
2. Click “Share” → “Manage apps”
3. Make sure the API was enabled for third-party integrations
Then I re-copied the new personal token (not the old API key—different thing now) and reconnected it in Make. Only then did the test connection show actual record previews.
Pro tip: Watch out if you’re duplicating bases. The token doesn’t auto transfer permissions across duplicated workspaces. That caught me once too.
Create a view for only the posts you want
Airtable by default shows everything. If you’re scheduling WordPress posts from it, you don’t want every draft, idea, and unapproved headline firing off at 3am.
I created a view in my Posts table called “Ready to Publish.” It filters like this:
– Status field is “Approved”
– Published checkbox is unchecked
– Scheduled Date is before now
That last one is key. Make doesn’t care about your Airtable formula columns. It doesn’t know your intentions. It just asks, “Can I find records in this view?”
So only when everything in the row is ready—title, content, publish flag—it shows up under that view, and Make treats those as ready to send to WordPress.
The watch records trigger is weirdly literal
Make gives you an Airtable trigger called “Watch Records.” This thing only fires when something changes.
But here’s what nobody tells beginners (and what cost me a full afternoon): if you schedule a post in Airtable with a publish date in the future…and then just leave it…Make won’t do *a thing*. Even when that date arrives.
Why? No cell was updated. So no trigger.
The fix? You either:
– Schedule a recurring Make scenario to check for matching records
– Or, every 5 mins, search for “Ready to Publish” view records (instead of relying on Watch Records)
That’s what I did. I replaced Watch Records with a Search Records module that runs every 15 mins. For each record that matches, it pushes to WordPress.
Yes, technically a little less efficient. But it actually works 😅
WordPress integration breaks silently with missing slugs
So I fire up my first scenario: new record → Create WordPress Post. Everything maps fine: title, content, publish datetime. But nothing publishes. Or sometimes just a blank article with no URL.
Turns out WordPress requires a slug if you’re publishing immediately. Make doesn’t throw a clear error on this. It just quietly creates a post with garbage data. Took me forever to notice because no one ever told me the slug field wasn’t optional.
What’s worse: if slug isn’t lowercase, or if it has spaces, WordPress will mangle it.
So I had to add a Make module just to transform the Airtable title into a slug:
1. Lowercase the string
2. Remove special characters
3. Replace spaces with hyphens
Used this Make function inside a Text Aggregator: `replace(replace(lower(title); ” “; “-“); “,”; “”)`
Then mapped that to the slug field. Now everything actually shows up normally in WP.
Scheduled posts publish late without timezone logic
Okay strap in: Airtable doesn’t handle timezones the way you’d expect. You see “June 4, 5pm” and assume it’s your local time. But if you’re on Make, it grabs the raw timestamp — often in GMT.
So my “5pm posts” were going out at noon. Classic 😛
The solution: I added a formula column in Airtable called “PublishTimestampLocal” using this formula:
`SET_TIMEZONE({Scheduled Date}, ‘America/Los_Angeles’)`
That corrects the local time in Airtable’s display—and ensures Make pulls the right version. Then in the Make module that posts to WordPress, I format the datetime like this:
`formatDate(ScheduledTimestampLocal; “YYYY-MM-DDTHH:mm:ss”)`
Suddenly my calendar and publishing schedule matched. Imagine that.
Updating the Published checkbox after posting takes two steps
After a post goes out, I obviously want to mark that Airtable record so it doesn’t publish again. There are two ways I tried:
1. Update the “Published” checkbox field inside the same Make scenario
2. Or create a separate Make scenario that watches WordPress and syncs back to Airtable
Option 1 is faster, but you have to remember to pass the Airtable record ID all the way through the chain.
So my Make flow ends like this:
– WordPress Post → OK
– Then: Update Airtable record → set Published = true
But if you forget to save the Airtable record ID early on — like from the original Search Records module — you can’t come back and find that row. I’ve messed this up twice and ended up re-publishing the same blog post because it wasn’t marked off properly 🙃
Now I always store the Airtable record ID in a variable at the top of the flow. Just a tiny thing, but it saves so much debugging.
What happens when the WordPress module just times out
Once you get confident, you start scheduling batches of posts. I had 10 queued up, Airtable view looked perfect. Hit run. Nothing happened.
It took me *way* too long to dig into the scenario execution logs. Turns out, the WordPress module would stall for about 30 seconds, then error with: “Unexpected response from server (504).”
This was a shared hosting issue. The site couldn’t handle that many API requests in a short burst.
So instead, I added a 1-minute delay between each post using a simple iterator + sleep action in Make. That totally fixed it. Posts stagger in, around one per minute, and my server doesn’t choke anymore.
Here’s a sample log of what Make ran:
“`
[2024-06-02 12:15:05] Create post: Automate Airtable → Success
[2024-06-02 12:16:05] Create post: Trouble with Slugs → Success
[2024-06-02 12:17:05] Create post: WordPress Timeout → Success
“`
Yes, it’s slower, but at least it’s reliable now. And I don’t get scary emails from my hosting provider 😅
Airtable formulas are powerful but not foolproof
Everyone tells you to use Airtable for scheduling because it’s “flexible”. But oh man, some formulas break if you so much as breathe on them.
For example, I created a formula like:
`IF({Scheduled Date} < NOW(), "Yes", "No")`
Then used that in my view filter: only show rows where Result = “Yes”. Made total sense.
Until I discovered that the formula doesn’t auto-refresh every minute. If no cell changes, Airtable just...stays frozen in time. The record still says "No" even when the date has passed.
So the view stays empty, even when it *should* catch those posts now past-due.
Only fix? Go into Airtable and gently nudge a row (date tweak, checkbox toggle), which causes the formula to re-evaluate. But obviously that defeats the automation.
So instead I rebuilt the view to reference plain Date fields, compared via Make.
Moral of the story? Airtable views are good for static conditions, not dynamic time comparisons. Let Make do the heavy lifting when possible. Airtable is *not* a scheduler. It's a database. Treat it that way :)