This post is in response to the 4/4/2022 email announcement titled “Changes to Airtable attachments” which announced that static URL’s will be going away.
This has a HUGE and sadly dramatic affect on my application. I’m using Airtable to crowd-source content for a weekly email - each member submits a form with their content, and I use formulas to roll together all the content into an automated weekly email, including images. It seems with this change that using static urls (as obtained via a formula and embedded into HTML tags) will no longer be possible.
I’m not sure how else I can embed photos into the emails I send out. I’m hoping someone can help think this through. A HUGE part of what I’m doing is about automating the compilation of multiple contributors into one email… it’s been working brilliantly for years… I’m so sad about this. I don’t know what to do…
Welcome to the Airtable community!
Yes, this is a big change. Thankfully we have been given several months notice to figure things out.
I am hoping that Airtable will provide more information about how attachment urls will work, especially
You can include attachments in automated emails. That should still work, as it creates an actual email attachment versus a link.
Yeah, it’s weird that they would remove this capability, since many people depend on it.
And attachments won’t work if you’re trying to embedding images inline via HTML tags.
My guess is that your solution will involve uploading your images to a cloud drive somewhere (Box.com, Google Drive, Dropbox, etc.) and then using their public URLs in your email. And you will most likely need to use an external automation service like Zapier or Make.com to handle all of this.
I feel your pain!
This will have a huge impact on multiple workflows for me. I sort of can’t even wrap my head around it right now. This is an enormous loss of functionality. I guess I know how I’ll be spending my summer.
I can almost understand this announcement being about security when it comes to files other than images. However, I assume static URLs to attachements is used overwhelmingly by users who link to image attachments.
It’s truly devastating.
Very worrying news here as well. We use thousands of records and their image attachments as the base of a huge product catalog on our website, using the Airpress plugin.
This change is giving me headaches.
Thanks Scott - yup, this is exactly my fear. Until now we’ve been able to do everything just using Airtable - with this change it will require huge changes to our processes, more coding and API’s. It’s just devastating… I’m so sad they are doing this. Is there any way we can appeal this?
Hi @ScottWorld, the issue with that option is there are image limits.
I am trying to use Google Drive to attach one image to a record, but the image limitation is low.
I have about 1,000 images and this news from Airtable will have a far reaching effect on attaching images, which is a common functionality in Airtable.
Especially for me!
This change, regardless of why AT is doing it, can probably be addressed by automations, Zapier or Make, and a cloud storage provider like Google Drive, DropBox, or even AWS S3.
Yes, there are more complicated versions of this – multiple attachments, creating folders for records, etc. etc. And I will admit that maybe I’m missing something fundamental. But the core problem seems solvable with no code/off the shelf tools.
Indeed, but, ya’ should have known. I predicted this change in 2019 and even encouraged Airtable to weigh in on the risks associated with the idea that (a) it makes no sense to treat image URLs as immutable and sustained, and (b) that it makes no sense to assume that Airtable (a database for small systems) is also going to provide you with a globally sustained CDN for free.
If you’re a total geek and recognize the importance of data architectures that include binary artifacts by reference, not by value - you might enjoy this thread from about three years ago where I predicted Airtable would eventually realize their shortfalls in the attachment design.
Evan Hahn (Airtable Engineer with Deep Insight)
… can’t guarantee fully static URLs
Bill French (Mr Nobody)
Nor should you. Related to this topic are the attachment URLs themselves (which are publicly accessible). I (and many of my clients) have trepidation about this and it is a factor that often rules out Airtable as a choice. Unbeknownst to most users – all attached documents in a base are openly exposed in a CDN-like environment (i.e., dl.airtable.com 6 ). I get it - the hash-keys for any given document are unpredictable and this is the basis for claiming they are secure. “Security by obscurity” are often the last words any CEO remembers just before seeing the “On-Air” light flash from a chair at CNBC as they queue up Kate Fazzini 6 to drill you about a security breach. I have to believe you and the team are pondering how and when this design must change. Have you considered signed-URLs 6 and a new API method that would give us the ability to create signed URLs for attachment documents?
The party ended in 2019; we just didn’t know it.
Airtable’s support pages and Airtable’s REST API documentation have been warning about URLs not being permanent for at least a year, and quite possibly several years before that.
In fact, the REST API still has the warning that it has always had:
Note: These URLs do not currently expire, but this will change in the future. If you want to persist the attachments, we recommend downloading them instead of saving the URL. Before this change is rolled out, we will post a more detailed deprecation timeline.
Yep - this is a safe assumption and Airtable could have managed this better. But there have been warning signals here in the community going back as far as 2018. Inexperienced database makers don’t typically think about the architectural consequences of using a feature designed for internal use in an external dependency.
Airtable promised that you could upload attachments as “copies” of documents and images and they have upheld that promise. They never promised immutable and sustained addressability to those attachments outside of the Airtable UI. This is the gotcha’ moment that everyone is surprised about and some of us saw it and warned of it for many years.
I’m surprised you’re all surprised.
I did a quick search and I alone have warned of this delicate and likely-to-vanish pattern 27 times in this community. Most of my threads are related to API-uploads that are unreliable. And in those specific threads, I advised clients and all users to consider the idea that in mission-critical applications where there is a distinct dependency on binary artefacts, you best address them by REFERENCE, not by VALUE.
The key takeaway is that it was never a good idea to lazily make copies of artefacts. Imagine a 10k image, a 100k image, and a 100GB video. At what point do you realize that making copies is impractical? Sadly, we use size as a justification for convenience and tolerance of the laziness Airtable has afforded us historically. It’s just 100k - no big deal, right?
As it turns out - it’s a big deal irrespective of size.
Binary assets are best integrated into data systems by reference, not by value. The requirement to manage digital assets separate and apart from the data model always existed; we just chose to sidestep those requirements for simplicity, faster time-to-production, and for our own profit of course.
The party’s over.
Bill, with all due respect, your reply is nonsense.
The overwhelming majority of people who depend on Airtable do not understand or care about “data architectures that include binary artifacts by reference, not by value”
Airtable is a no-code tool that works magically in its current state for us plebes who care more about the sausage than how the sausage is made.
If you decide to use Airtable’s internal links in ways that its no-code product did not intend and openly advised against, you have a responsibility to understand and care deeply about data architectures that include binary artefacts by reference, not by value.
Indeed, it works as expected with attachments. It never failed before this change and it will not fail after this change. Anyone affected by this change chose to design critical systems with an unorthodox approach. Leaning on CDN URLs as if they were part of the “product” is a mistake not just with Airtable - with every vendor except, of course, vendors who provide CDN services such as Cloudinary (for example).
With all due respect to your respect, if you believe this is nonsense, read the ToS for any number of no-code platforms, many of which do not even chance the exposure of attachment URLs for exactly this reason.
No debate - Airtable has handled this exposure poorly, but there’s plenty of evidence to suggest your contract with Airtable is related to all things in the Airtable app. They will capture your images and host them for purpose of recalling them and displaying them in the UI. However, they will not host them externally for any scale that you may see fit to subject them to. This doesn’t seem to be an irrational position. Would you accept the responsibility of presenting an image requested 300 million times a month for $24?
If my reply is nonsense, your assertion is irrational.
I feel that Airtable did not adequately advise against this usage. There is a post in this community forum that advises against this. Finding this post involves knowing to look for it. There are the legal terms and conditions that can be interpreted to mean this, but do not explicitly state this.
On the other hand, there has been a proliferation of third party products and services that take advantage of using Airtable as a CDN without any apparent backlash.