New: Remote fetch in Scripting App

[Taylor_Savage]

Happy February! We’re excited to announce that our new remoteFetchAsync function is now live within the Scripting App.

One of the most common issues we see users run into when writing scripts is in trying to use the fetch API to communicate with an external service. Because Scripting App scripts run directly in the user’s browser, fetch requests will be blocked by the browser if the target server doesn’t support Cross-Origin Resource Sharing (CORS).

The new remoteFetchAsync method transmits the request from Airtable’s own servers rather from the user’s browser, thereby getting around CORS issues. remoteFetchAsync works very similarly to fetch and expects the same inputs, except for a handful of “gotchas” stemming from the fact that this is run from a backend.

Resources to get started:

1. Read documentation: Learn about the functionality of remoteFetchAsync here.
2. Share your script template with Airtable customers: Already built a script that utilizes backend fetch? Submit here to get it listed in the Airtable marketplace.

Let us know if you have any questions or feedback in the comments below!

[Bill_French]

Taylor_Savage:

why specifically Google Apps Scripts?

Um…

• Free
• Reliable
• Agile
• Pervasively used by 100 million business worldwide
• Almost every Airtable customer is on Workspaces
• Consistent javascript client-side and server-side
• Seamless support for 85 SDKs in the Google ecosystem
• Native interface to Maps, Drive, Documents, Sheets, Search
• Seamless pathways to data at scale (Firebase, Big Data, etc.)

Taylor_Savage:

Is it that it’s the simplest environment to write script-style code that’s a) accessible via a public URL endpoint and b) has a lot of flexibility in terms of what you can actually do within the environment? Or that it can easily interface with other Google products? Or something else?

Yes, yes, yes, and yes - and many something else’s.

And now there’s Google Tables (an early attempt to create a no-code database veneer).

[Joe_Duffy]

Thank you! I am trying to implement the remoteFetchAsync function to call a POST API. I haven’t had any luck yet and I’m not sure if I’m doing it correctly. Do you happen to be free to join a screenshare this week?

Thanks again!

Joe

[David_Brownman]

Awesome @Taylor_Savage! What a great feature.

Curious - is similar functionality coming to Apps (aka Blocks)? I’ve had to work around some CORS issues there as well.

[Carlos_Cardona]

Hi @Taylor_Savage I was able to get remoteFetchAsync in my trigger script but when I try using it as part of an Automation Script it’s telling me that “remoteFetchAsync” is not defined. I can’t use “fetch” due to the CORS issues. Thanks for your help.

[Taylor_Savage]

Hey David! We’re definitely considering a similar functionality with Blocks - just a matter of prioritization on our end.

[Taylor_Savage]

Hey Carlos! Automation Scripts already run in the backend, rather than in a user’s browser, so you shouldn’t run into CORS issues in Automation Scripts (and so don’t need remoteFetchAsync). Maybe something else is causing the fetch to fail?

[Carlos_Cardona]

Got fetch to work in Automatons. thanks.

[Sebastian_Muril]

Hey @Bill.French, I completely agree with you here. Do you know if there has been any update in this front? I’m trying to call a GAS webhook and having a real hard time with both fetch and remoteFetchAsync.

Any successful examples you’ve seen out there?

[Bill_French]

No changes from Airtable that I know of, but this pattern seems to work well with Google Apps Script hosted webhooks. The issue, of course, is that I believe the response from the webhook service is sent but not detected by Airtable.

// get the location for this order
let gWebhookURL = "https://script.google.com/macros/s/AKfycbyvaERhqYfV1U14GjzSfeg_MeR2GawIzbImok4HlCH2JAp7tg/exec?token=gff67yt290&task=build-additionalpayment-document&id=" + thisID;

// call the webhook service
try {
  await fetch(gWebhookURL, {method: 'get', mode: 'no-cors', redirect: 'manual'})
  // the response will be a web page redirect that Airtable cannot follow
} catch (e) {
  // do nothing... (airtable doesn't support follow redirects so this should fail every time unless redirect:manual is passed)
  console.log("FETCH: " + e.message);
  console.log('FAILED!');
}

[Sebastian_Muril]

Ahh, I see. I’m getting a “Failed to fetch”… Would this be enough to trigger the script in GAS? If so, I can have the script in GAS pull the data from Airtable and keep the UI all in Airtable. Maybe that could be a workaround, what do you think?

Also, is thisID for the Deployment ID in GAS?

Thanks for your help.