Help

Random 404 responses from airtable api

Topic Labels: API
Solved
Jump to Solution
15044 36
cancel
Showing results for 
Search instead for 
Did you mean: 
Paul_Kortman
6 - Interface Innovator
6 - Interface Innovator

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:Screenshot 2019-10-02 17.16.12.png Screenshot 2019-10-02 17.19.36.png

(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?

36 Replies 36

I don’t understand what you are asking here?

If there were values “missing” then it would fail with different errors further in the Zap… zapier’s webhooks have no required responses. So even if the response was malformatted (which it’s not) or missing values I would get different results. The 404 comes from Airtable.

Nope, the text you’re reading is the “help text” from Zapier for API novices to say “hey, you might be getting an error from your API because one of the fields we sent to the API was empty” – it’s help text on any error with webhooks. In my case the values are all set and there’s no possibility for an “empty” value being sent to the API (all it is is GETing the records in a specific view)

As we know, an API request for a record that has 10 columns, five of which have data, will return that record without the empty fields represented in the result - i.e., . only five fields that actually have data.

Just a hunch - is it possible the Zap is accommodating two of three possible result occurrences and missing 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, right?

Again, I don’t know Zapier that well, but it is a middle-ware API service that must interpret and report errors from 1500 different APIs. How it handles each of them could be giving you inaccurate assessments of failure.

I’ll be waiting for the beer. :slightly_smiling_face:

That would be my choice as well.

You are making some huge assumptions here… Zapier doesn’t expect the result at all. So 3 records with only 3 fields each or 1 record with 1 field or 0 records with 0 fields (empty resultset) all are the same to Zapier (in this case, since it’s just a simple webhook)

I have already worked with the Zapier team to determine that the 404 error is indeed coming from Airtable and the missing element is the table as the error says.

Zapier knows how to handle errors, so please stop trying to claim it’s a Zapier problem.

Understood - I’m still learning and it seems you have exhausted Zapier as the source of your headache.

I guess you need to focus on Airtable failing to support consistent requests for your data.

To be clear - I’m only suspecting Zapier as a potential source of your troubles. My hunch is that that something in the data has changed and the Zap is unable to deal with it.

If the folks at Zapier have details that prove this is an Airtable failure, you simply need them to explain it to @EvanHahn with actual data.

I’m curious to see what the outcome is.

EvanHahn
6 - Interface Innovator
6 - Interface Innovator

Unlikely. 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. I think all of that is pretty unlikely, especially given the discussion above.


@Paul_Kortman Here’s a wild question: are all of these requests using the same User-Agent header? Are you able to see that in Zapier’s logs?

A less wild question: is there anything different between a successful request and an unsuccessful one, other than timestamps? Are the outgoing requests any different?

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.

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.