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?

[Bill_French]

Thanks Evan,

EvanHahn:

It’s possible that we’re not returning a field for whatever reason, and then Zapier chokes on that (for some unexpected reason) and then, inexplicably, makes it look like we’re returning a 404.

Hmmm, that’s exactly what I said here…

Bill.French:

… the third possibility where there is a result, but the payload is less than that needed for the Zap to process completely … bear in mind, the 404 you are getting from Zapier is an interpretation of the 404 Airtable may (or may not) be generating…

My money (um, beer) is still on the data/Zap; not Zapier, not Airtable. But lacking lots of experience with Zapier, the probability is I will be buying Paul a beer. :neutral_face:

[Paul_Kortman]

EvanHahn:

We should be returning 429 status codes with a rate limited response (in other words, not a 404). It’s possible that we have a bug somewhere, but I’m pretty familiar with our rate limiting code and would be pretty surprised to see this.

okay, so I’ll drop my suspicion on rate limiting. :slightly_smiling_face:

[Paul_Kortman]

EvanHahn:

are all of these requests using the same User-Agent header?

yes as it’s “hard coded” into my request Crud, upon further inspection it appears as the sucessful ones are using the Zapier User-Agent and the failing one had Postman as the User-Agent

Here’s a log from a successful request

Here’s a log from a 404 response

From what I can tell its the exact same request The user agent and the order of the headers are different, order shouldn’t matter but I’m guessing User Agent does?

EvanHahn:

Are the outgoing requests any different?

Just the User-Agent

EvanHahn:

Another thought: could you set up a similar Zap pointing to a different base and see if the problem persists there? That could help us determine whether this is a broader issue.

I could but I’m going to test the theory on the User-Agent and get a hold of Zapier as they shouldn’t be sometimes using one and sometimes another if I specified the User Agent

[EvanHahn]

Paul_Kortman:

The user agent and the order of the headers are different, order shouldn’t matter but I’m guessing User Agent does?

If you wouldn’t mind, I’d follow up with Zapier to see why they’re changing the User-Agent header, and if they can make it consistent. I am 99% sure that’s the right thread to pull on, if not the actual issue.

It’s literally possible for the order of the headers to be the culprit (they’re sent in some order), but I don’t know of any API-related code that relies on header order, and would be pretty surprised if that were the problem.

[M_k]

Hi @Bill.French

Well, who gets a free beer? :grinning:

Kidding aside, I found this discussion quite interesting!

Mary K

[Bill_French]

M_k:

Well, who gets a free beer?

I’m not sure. My money was on the Zap or the data as the likely cause. @Paul_Kortman insisted it was Airtable.

Paul_Kortman:

… it appears as the sucessful ones are using the Zapier User-Agent and the failing one had Postman as the User-Agent.

Do we know what the true cause was yet? I have no clue how the user-agent is controlled in a Zap.

[EvanHahn]

Bill.French:

I’m not sure. My money was on the Zap or the data as the likely cause. @Paul_Kortman insisted it was Airtable.

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!

[Paul_Kortman]

@EvanHahn I’m still waiting on Zapier support to respond to my latest message (from last night) but they did remind me of something I knew from testing but had no confirmation on:

If a webhook makes a request to https://api.airtable.com/v0/{appId}/{table name} it does not work with the User-Agent: Zapier header, which we automatically add. It returns a 404, “table not found” error. However, if you use the table id , or if you remove the User-Agent: Zapier header, it will work.

This is why I specified a user-agent of Postman, however the log files they provided show the opposite is true, when its sent with a user-agent of Zapier its sucessful with a {table name} and when sent with a user agent of Postman and a {table name} it fails.

I’m guessing you have it written in the API to detect the user agent of Zapier and then accept only {table id} for the API calls, correct? Why on earth would you do that in the API and not add a switch versus a user-agent detection?

[EvanHahn]

Paul_Kortman:

I’m guessing you have it written in the API to detect the user agent of Zapier and then accept only {table id} for the API calls, correct?

I believe that’s the case, yes. I also think there are some other pieces of the API that behave differently in this case, but I can’t elaborate on the specifics.

Paul_Kortman:

Why on earth would you do that in the API and not add a switch versus a user-agent detection?

A lot of these decisions were made before I even joined the company, so I don’t have a lot of historical context on this. If it’s important, I can try to trace down the answer, but I’m not sure we’d even be able to share that publicly even if I did get the answer.

If it were up to me, we would have no Zapier-specific code on our end, but we have a little bit, which might be explaining your issue.

[Paul_Kortman]

EvanHahn:

A lot of these decisions were made before I even joined the company, so I don’t have a lot of historical context on this. If it’s important, I can try to trace down the answer, but I’m not sure we’d even be able to share that publicly even if I did get the answer.

aka I could tell you but then I’d have to kill you…,… nice

I don’t need the answer, just someone else to commiserate with me that having an API behave differently based on a user-agent is not best practice and kinda absurd imo.

EvanHahn:

If it were up to me, we would have no Zapier-specific code on our end, but we have a little bit, which might be explaining your issue.

We’re on the same page here.

I think the most frustrating thing is the lack of consistency within Zapier, it should always succeed or always fail if it were consistent in sending over the user-agent I specified.