Inconsistent data retrieval from Airtable API causing duplicate records

Other Questions Airtable
1

I’m working with the official Node.js Airtable library and running into a weird issue. When I search for records using filterByFormula, the API sometimes returns the record and sometimes doesn’t, even when I know the record exists.

My workflow is simple - I check if a booking already exists in my table. If it does, I update it. If not, I create a new one. But because the search fails randomly, I end up with duplicate entries.

Here’s how I’m searching for existing bookings:

findBookingByReference: async (refNumber) => {
  let bookings = await reservationTable('Bookings').select({
    view: 'Grid view',
    filterByFormula: `{Reference Number} = "${refNumber}"`,
    maxRecords: 1,
  }).all();

  return (bookings.length > 0) ? bookings[0] : null;
},

And here’s how I use it:

let existingBooking = await findBookingByReference(booking.reference);
if (!existingBooking) {
  addNewBooking(booking);
} else {
  modifyBooking(booking);
}

The problem is that sometimes existingBooking comes back as null even when the record definitely exists in Airtable. This causes my code to create duplicates instead of updating. Has anyone experienced this before? Am I missing something obvious here?

2

Yeah, I’ve hit this exact same issue with Airtable’s API - super frustrating. Sounds like you’re running into their eventual consistency problem where the API doesn’t immediately show recent changes across all servers.

Here’s what fixed it for me: I built a simple retry loop that tries up to 3 times with 500ms between attempts. Gives Airtable’s backend time to catch up. Also started using record IDs for updates instead of just formula searches - cuts down on these race conditions big time.

One more thing - double-check your Reference Number field for weird characters or spaces. I’ve seen certain characters randomly break filter formulas.

3

sounds like airtable’s caching is screwing with your batch operations. i’ve hit this before. try adding a timestamp to your queries or use the cellFormat parameter - it usually forces a fresh lookup. also check your reference numbers for trailing spaces - they’ll break everything without any error messages.

4

This happens because Airtable’s API caching is inconsistent. I hit the same issue building a booking system last year. The API serves stale data from different cache layers, so new records don’t show up in queries right away. Here’s what fixed it for me: I started doing a two-step check. After creating a record, I immediately query it back using the record ID to make sure it exists before moving on. For searches, I added a backup that tries different field combinations if the main search comes up empty. Also check your field formatting - I found that reference numbers with leading zeros or special characters were breaking filters silently. The formula would run fine but randomly return nothing.

5

Had this exact headache 2 years ago building an inventory sync system. It’s not just eventual consistency - Airtable’s concurrent request handling is messy.

What saved me: proper locking mechanism. Before checking for existing records, I create a temporary “processing” flag in a separate field. Stops multiple requests from trying to create the same record at once.

Your filter formula might be the problem. Try FIND() instead of direct equality:

filterByFormula: `FIND("${refNumber}", {Reference Number}) > 0`

This catches invisible whitespace or encoding issues.

One more thing - you’re using maxRecords: 1 but still calling .all(). Switch to .firstPage() for single record queries. It’s faster and more reliable.

If it still breaks, add a unique constraint at the database level using Airtable’s built-in duplicate detection, then handle the API errors when duplicates are attempted.

6

I’ve run into this before - it’s usually a timing issue. Add a small delay before searching, or better yet, switch to webhooks instead of polling. Also check if you’re hitting rate limits since Airtable gets finicky when you hit it too hard. Throw in some logging to see if the record actually exists when the search fails.