Changes to Airtable's attachment URLs 11/8/22

Hey everyone!

I know a lot of you use Thunkable’s integration with Airtable to host attachments that are retrieved within your Thunkable apps. Starting next Tuesday, November 8, 2022, Airtable will update Attachment URLs to expire after a short period of time (~2 hours).

This may impact you if your app is using hardcoded Attachment URLs or relies on static URLs for longer periods of time. If this is the case, you may need to update your blocks to request the URL more dynamically or frequently.

All other uses of the Airtable integration with Thunkable outside of Attachment URLs are expected to work as normal.

For more information, please reference Airtable’s support documentation. We recommend those who are using Attachment URLs to reference this documentation and/or reach out to the Airtable team for assistance!

Happy Thunking,
@conroy and the rest of the @Thunkable_Staff


Really appreciate the heads-up! Thank you.

From my quick reading of the documentation, we pretty much can’t use Airtable or the Airtable API any longer to store and retrieve images for use with Thunkable.

So I guess it’s Cloudinary now. Which brings me to these feature requests which become even more necessary now:

Picture resize before uploading to MediaDB

Photos uploaded to Cloudinary remain on device, taking up space

1 Like

hmm i have some images as attachment because cloudinary stop host my file after a while and my webhost is cheap an goes down alot so i would have look to host my files else where now ahhhgh

Hi @conroy and the others at Thunkable,

I just stumbled over your message that starting with November 7th 2022 the URLs of elements in Airtables attachements expire after approx. 2 hours. This leaves 6 days for me to to change my apps (I have 3 apps in the stores). Digging a little deeper at Airtable shows me that they announced this type of change back on April 4th 2022. This rises several questions to me and to Thunkable:

  • Thunkable has no built in database and relies on external providers like Firebase, Airtable or Google spreadsheets. Using those external databases in a secure and reliable way should not only be the responsibility of the user but also of Thunkable. I myself feel a little bit disappointed that Thunkable did not send out warnings to users, or did I miss something? Maybe a dedicated section “Urgent changes” or so in the support would help like “From x.x.2022 on the new API level 31 in Android is required” or “To all users of airtable attachements…” etc., maybe with the option for me to get this messages directly via email?
  • I have to pay for Thunkable and I have to pay for Airtable. And when a customer has two vendors they play ping-pong with the customer when anything goes wrong like “RTFM (read the fine manual) of the other vendor”. Exchange the word “fine” with something more suitable. So who can help me out now? Airtable has a very nice and easy to use GUI for entering and managing data. This is superior over other databases so right now moving away from Airtable is not a short term solution for me. And moving away from Thunkable to a no-code-provider with a database is also not a short term solution.
  • What should I do with apps that work with DVLs? The DVLs get filled up when the app starts and there are several nice layouts that make use of pictures and icons from an airtable base. Those pictures and icons are stored in an attachement field. What happens after 2 hours? Do I get errors in my app when I tip on a DVL (data viewer list)?

Best, Michael.

1 Like