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!

[Sebastian_Muril]

Or maybe even an Integromat webhook could do the trick? And from there I can trigger the GAS script. But not sure if this is possible from the Script App either.

[Bill_French]

Sebastian_Murillo2:

Would this be enough to trigger the script in GAS?

Yes. That’s precisely how it is used in this case.

Sebastian_Murillo2:

I can have the script in GAS pull the data from Airtable and keep the UI all in Airtable.

Yep - I do this all the time.

Sebastian_Murillo2:

is thisID for the Deployment ID in GAS?

It’s the endpoint of a webservice deployed in Google Cloud using Google Apps Script.

[Sebastian_Muril]

Bill.French:

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

Hey Bill, I’m trying to put together the endpoint but not sure I’m in the right path. Is this the right logic?

The gWebhook URL is made up of: Web App URL + “?token=gff67yt290&task=build-additionalpayment-document&id=” (where does this come from?) + Endpoint of webservice deployed in Google Cloud (am I in the right place in the Cloud console to get this ID from?)

Where:

Web App URL:

Endpoint of webservice deployed in Google Cloud:

Thanks again for your help or any docs that you think can point me in the right direction :pray: .

[Bill_French]

Sebastian_Murillo2:

I’m trying to put together the endpoint but not sure I’m in the right path.

Google makes these URLs and because of this, they are somewhat secure. You must deploy a web app to get a working URL for that web service.

[David_Brownman]

Hey Taylor! Just wanted to check in here- is bringing the server-side fetch functionality still planned for Extensions (previously Blocks)? It would be super useful, personally!

[bbloch]

@Taylor_Savage Is remoteFetchAsync still available in custom extensions?  Every time I run it, I get an error saying it is undefined.  Is there an example that can be referenced?