Automations error (but not on Block): Response status was 302 'Moved Temporarily' but redirect mode was set to 'error'

Yes! I am getting that same error just in the last 3 days, and only when it is run as an automation.

You can see below that it worked fine for several days, then 3 days in a row it failed, with the message you described (except mine says it was “permanently” moved):

In my case, the API I was using did change their URL scheme. But I adjusted my script to match their new URL scheme after that very first failure. I verified that it worked. Next day, it failed to fetch from the updated URL with the same error. Today, it seems to have corrected itself :man_shrugging: . Who knows?

Thank you and super interesting! Hope it corrects itself.

It looks like Google Scripts Webapps don’t actually expose the final URL for security reasons, so what’s served up as their endpoint is actually just a redirect.

For some reason, Airtable Scripting Blocks can follow that redirect correctly, but automations can’t.

To illustrate – the expected value returned is “128” here.

SCRIPTING BLOCK

AUTOMATION TOOL

Ya – clearly it’s got something to do with the fact that scripts in the scripting block (or being tested in the automations interface) are running locally in your browser engine, whereas automations are running on a cloud server (probably AWS).

@Kasra, @Stephen_Suen, @Billy_Littlefield, @Zach_Felsenstein, @Jason – heads up

This is accurate; it’s always been this way (many years actually). But I wonder, would this header request addition help?

followRedirects: true

Thanks! I’m unfamiliar with the followRedirects parameter but I gave it a shot in the header and it didn’t work. I also tried the “redirect: follow” parameter and received this error:

That does appear to confirm the issue. Wonder if there are any workarounds.

Update: I was able to write a workaround using Pipedream.

Workflow was Airtable view trigger > node.js script that fetches the Google Script JSON object > Airtable Patch to update cells

Functionally, this runs almost exactly the same way Airtable’s Automations would run, but it looks like Pipedream allows for redirects on GET requests.

If there’s interest I’m happy to share the workflow.

This seems to be an accurate assessment of the issue.

I think the right approach (when attempting to create a seamless integration between Action Scripts and Google Apps Script) is to make requests using the redirects : "follow" option in Fetch().

let postOptions = {

    method: "post",

    headers: {

        'Accept' : 'application/json'

    },

    redirect : "follow",

    body: JSON.stringify(payload)

}

When doing so, the error message is far more revealing: Airtable simply doesn’t support the ability to follow API platforms that require response redirects. I also see no workaround for harvesting the response.header.location to perform the correct [redirected] request.

I believe Airtable needs to remedy this and soon because it makes it entirely impossible to integrate Google Apps Script, Google Cloud Platform, and many other systems that use this technique for stringent security measures.

My workaround (for now) is a Firebase or Google Cloud function as the proxy much the way @Mike_Mauer has done with PipeDrive.

@Kasra?

To confirm, as @Bill.French says, we don’t currently support following redirects when using fetch in Automation scripts. The differences from fetch in the browser section of the automation scripts API docs has some more details of this and other limitations of fetch in automations at the moment.

We can’t share a timeline for when redirects might be supported, but thanks so much for the feedback - it’s super helpful for us prioritizing work on this sort of thing in the future. Let us know if you come across any other use-cases where you need redirects in automation scripts!

Hacky workaround -

• Make a POST, let it fail (because it probably succeeded).


• Let the called service backfill the Airtable table with a response/outcome.

Super annoying. I am writing enough code to forget this is a no code platform yet failures…

Any chance you could elaborate here Bill on the POST and backfill.

Sure.

The POST is the easy part; plenty of examples like this.

If you can use a POST to at least push the record ID to the external process (like a script in Google Apps Script or AutoCode), that process can call back into Airtable using the API, perform everything it needs to, and then update Airtable itself with results and or call into other systems.

This approach is ideal in cases where 302 redirects are required to get the results back. Lacking a response, all you can do is have the external process complete the action. Kludgey, but it works.

Ok, thanks. I am actually just trying to fetch a .wav file from a URL but I get the same pattern of errors in this post.

Okay - so we can safely say that the domain hosting the .wav file is employing redirects (probably for security reasons) and if so, you need a proxy in the middle that can take a request from Airtable, make the request using redirect : "follow", and then return the data to Airtable.

I would take a look at the idea of using AutoCode for this; they have a generous free tier of like 100k requests per month.

Thanks. I am already processing parts in Zapier and will try them first.