Random 404 responses from airtable api

[Paul_Kortman]

For the last couple of weeks, I’ve been getting new 404 errors on API calls that used to work perfectly every time.

The API calls run every 5 minutes or so, and 90% of the time it works great, but now 10% of the time I’m getting back an error that says the table cannot be found. This is crazy as the table remains and in just a few seconds/minutes when the next webhook runs it will find the table and run correctly.

These 404s are causing significant problems, especially when I’m testing for a record and I get back a 404 my script thinks the record does not exist… but that’s not true. In my oponion this should be more of a 500 level server error.

Here’s the calls I’m making and the errors I’m receiving:

(yes these are from Zapier, and yes I had to spoof the user-agent to make it work)

I’m calling https://api.airtable.com/v0/appU29NNGxB8qigRN/Main%20Table
I get a 404, “We made a request to api.airtable.com and received (404) Not Found.” Specifically saying:
“Could not find table Main Table in application appU29NNGxB8qigRN”

I reached out to airtable support and their response was: “It looks like the GET request looks identical so we can’t see any reason why one returns a 200 and one returns the 404. I would recommend posting in the Airtable Community Forum specifically in the API section.”

So here I am posting here, hoping that someone can point me in the right direction since airtable support cannot seem to?

[Paul_Kortman]

EvanHahn:

In reality, it may be a bit of both. I know Airtable has some weird Zapier-specific code, and it’s possible that Zapier stopped triggering that special behavior. So it could be everyone’s fault!

To my point with @Bill.French it isn’t Zapier that is mis-interpreting the error. (It is indeed Zapier’s fault for not being consistent) but (and I don’t know how the logic would work on this) perhaps there is a better error than 404 when a table name is given but a table id is expected… perhaps @EvanHahn that should be added to the future features, even if it is a 404, to be able to say in the error message a table ID was expected ... table IDs start with tbl etc OR something like that, so when someone is passing a table name and getting an error they know a table id was expected, and vice versa.

[EvanHahn]

Paul_Kortman:

having an API behave differently based on a user-agent is not best practice and kinda absurd imo.

I agree, and I disagree with our old decision. There may be some additional logic, too, and the User-Agent check just verifies that it’s coming from Zapier (for example, we might check that the incoming IP addresses matches Zapier and double-check the header, too), but I am not sure. In any case, I wish we had no code specific to a particular vendor. In practice, that sometimes has to happen for various reasons.

Paul_Kortman:

perhaps @EvanHahn that should be added to the future features, even if it is a 404, to be able to say in the error message a table ID was expected ... table IDs start with tbl etc OR something like that, so when someone is passing a table name and getting an error they know a table id was expected, and vice versa.

I’ll keep that in mind!

[Bill_French]

@EvanHahn - Thanks for helping with this issue.

Setting aside the absurdity part, I agree with Paul on this point:

Paul_Kortman:

… having an API behave differently based on a user-agent is not best practice …

I don’t think anyone intentionally tries to infuse absurd concepts into an API - they happen over time when it’s too costly to repay code debt. And I do know that there was a time when Zapier was cutting corners to make stuff work too.

Zapier comes with a lot of benefits and some risks as demonstrated in this thread. Any time middle-ware machinery is added to process automation, there are increased risks that have to be factored into the make-or-buy equation. Bring an off-road vehicle; it could get a little bumpy.

We can avoid pitfalls like this by building the middle-ware from scratch (my preference), but you need to bring a paving machine if you want a smooth road.

All said and now better understood, I don’t feel compelled to buy Paul a beer, but I think you both could use a beer so I’ll try to work out those logistics.

[EvanHahn]

Bill.French:

All said and now better understood, I don’t feel compelled to buy Paul a beer, but I think you both could use a beer so I’ll try to work out those logistics.

I can’t speak for Paul, but I’m good on the beer front—just glad I could help!

[Paul_Kortman · Accepted solution]

Update from my side on this… a Zapier engineer discovered that I was using user-agent in my webhook header and not User-Agent the capitalized version would overwrite the default User-Agent:"Zapier" whereas the lower case would be sent along with the default upper case.

We did see that the headers are sent in somewhat of a random order each time, so sometimes when two “user-agent” headers were sent the User-Agent:"Zapier" would go first, sometimes thw user-agent:"postman" would go first, thus the randomness.

Our guess is that airtable took the first one (regardless of capitalization) and would opperate that way.

So it is my fault for not capitalizing the U and the A… but also Zapier’s fault for sending headers in a random order, and they couldn’t explain why that happens.

Thanks for your help in diagnosing this problem!

[EvanHahn]

Glad we could get this solved!

[Robbie_Mitchell]

Paul, you’re a lifesaver!

For those wandering through who bumped into this same problem hitting the Airtable API from a Zapier webhook, the simple fix is this: add a header User-Agent with any value other than Zapier and your call will go through.