I cannot imagine Airtable announcing worse news. All of our content workflows will break. There is absolutely no way Airtable talked to their users about how this will impact them.

I’ve been searching all morning for an alternative and the best I’ve found is exporting our Airtable database to Xano (a no-code database) and rebuilding our automations there. I’m guessing that will set me back at least two weeks or more to complete.

I really hope there is enough user outrage that Airtable scaps this plan. And I totally agree that “security” is the thin veil reason. Incredibly angry right now.

Next to revealing the ability to edit records without logging in, and then pulling it a few hours later, this is Airtable’s dumbest move ever! We noticed the security issues of open URLs and exported CSVs just after we started using Airtable 3 years ago. But, as you say, there are other ways to deal with this particular security issue. Its going to break so much of our stuff.

We are a small club and we are not high-end users but we have tons of documents loaded in as attachments. I don’t understand the distinction between URLS that will continue to work just fine and others that will expire. I also do not know how to identify the ones that will break. This is a really confusing change and I hope that AirTable will change their mind on this.

If you used to copy the direct link of an attachment to share it with other people or services, this will not work anymore. The only thing that will keep working as usual are attachments you see within Airtable.

But the direct links to those attachments will expire and cease to work after a while.


I hope it’s a bit clearer.

Ambroise: thank you for the clarification. I am concerned about a sentence in the change description at https://support.airtable.com/hc/en-us/articles/4852449595671. The sentence is “If you are sharing a file with a colleague who is not collaborating with you in Airtable , then you will need to consider alternative ways of sharing the file attachment in question.” Several AirTable views are shared with some of our club members who are not collaborators. Some of these views include attachments (PDF files, Word files or pictures). Will our club members be able to view these attachments?

You should be fine. They are looking at a shared view that is provided by Airtable.

The text in the support article will probably be revised over time to make things more clear.

Only users who are logged in i.e. having a paid license will be able to access the static URLs. Say goodbye to Zapier automations that use the static links.

If you’re concerned about the recent change in Attachment URLs that Airtable just announced, we want to hear from you.

At On2Air, we’re exploring ways to overcome this. (We build apps for Airtable - on2air.com)

Let us know if interested and your use-case by filling out this form.

This change shouldn’t affect Zapier, as long as you are accessing the attachment field.

So we send an automated email that supplies a link like this: https://dl.airtable.com/.attachments/2d3e32a5dbd2d2318a7416eb9c96b456/dae8ba3d/NAME OF FILE.pdf) Will these no longer work in November?

What if you are using something like Softr where they can access the attachments via url?

https://dl.airtable.com/.attachments/…

@Mark_Comish I don’t fully understand how this change will impact everything, but my current understanding as of right now is that both of the scenarios that you outlined above will both break.

p.s. I’d also like to point out that many people in these forums believe that I am an Airtable employee. I am simply an independent Airtable consultant and an Airtable user. I don’t know any more or any less about Airtable’s announcements than anybody else in these forums. :grinning_face_with_big_eyes:

My understanding is that these types of links will work for a period of time and then expire. The exact duration that the links will work is not yet clear.

I thought I saw a reveal of about 30 minutes.

It’s my understanding that Softr saw this issue coming and long ago addressed the looming issue by ensuring their reference to attachment URLs was near-real-time and therefore, should be impervious to this change.

Correct. It’s my understanding the link reference will work if the recipient acts on it relatively soon after the email is delivered.

But this is not unlike any field values plucked from your database and shared through email. A message containing a customer balance, for example, has a shelf life - it will expire and potentially much sooner than attachment URLs will be sustained. Attachments can now join what has always been the case where assuming a static snapshot represents an historical perspective that may have changed since it was captured.

I think this is not entirely the case. Imagine Zapier is used to snapshot an attachment URL and sent it via email somewhere. Or, it sends it to a Google sheet. With the November changes, about 30 minutes later that URL will predictably fail.

While we may be quick to blame Airtable for this behavioural change, this problem has always existed. Images can be removed and replaced after a static URL has been shared. The links (unwisely still work) but in this case, they point to an old image - not the current one which may have changed in the past few minutes.

Bottom line - data shared by value - is a bad idea. It’s ostensibly the act of making a copy and as we all know, copies are ideal for historical perspectives, not real-time perspectives. If you want to create systems that always represent ground truth - i.e., the state of the Airtable data - you must share by reference and that reference would be a view or other such interface that Airtable possesses and is able to render without the interference of a historical timestamp.

This page currently says “a few hours”.

So if you saw 30 minutes, there is confusion somewhere.

Any attachment URLs obtained via the public API and the CSV export functionality will expire after a few hours.

It also says

The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid.

Does this mean that the urls from formula fields will stop working completely on Nov 8th or does it mean that they will continue to work for a few hours and you will get a new value every few hours (or some other interval)?

I am a starting to think the former. But the wording isn’t as clear as I would like.

I think that this support page used to refer to the url of an attachment, but I’m not sure. It sounds like people using this formula will still see a url, yet the support page currently has no mention of that url becoming invalid or expiring.

There are numerous community posts and third party tools about extracting URLs from attachments, and the silence from Airtable about these posts could be taken for approval.

I wrote an app for extracting these urls using a formula field that had to go through QA with Airtable, and I was never told that using these urls was discouraged. Unlike the community posts and third party tools, my app underwent a line by line code review by Airtable, so the lack of comment by Airtable against using urls in this way was even more evidence that Airtable was okay with using these urls. Airtable knew that my app extracted urls from attachments, knew exactly how those urls were produced, and published the app. This was less than a year ago. Why didn’t Airtable say anything before the app was published? If Airtable had said they didn’t want that formula in my app, I would have removed it. (Given that it takes months for a custom app to go through QA, I suppose that I should remove it now and hope that it makes it through QA by November.)

I also could not see any documentation on how long urls obtained by a script or custom app will last. What if a custom app wants to display an attachment? It needs to get the url of the attachment. How long will that url last? Could these urls last for the duration of the session if the session is longer than a few hours? If they expire while the custom app is still trying to use that url, how will the custom app be notified that it needs a new url?

What if someone uses the dev console to see urls? How long will those urls last? (Although I don’t recommend using urls obtained in this way, I do wonder, especially for urls consumed by Page Designer.)

@Jordan_Scott1 There seem to be a large number of unanswered questions about this upcoming change — would it be possible to get more clarification from Airtable on these changes?

I can only speak for myself, but I am somewhat confused by the announcement, because I’m unsure of what will break and what will not break.

Agree - it’s highly likely the former.

Ha ha! You are dreaming. You really think the left hand knows what the right hand is doing in cases involving deep technical coordination. Vastly bigger organizations with lots of depth and experience in coordination get this wrong. Airtable has as a well.

Events and/or pubsub architecture. The days of REST APIs are nearing their end of usefulness. Business requirements have raced ahead while vendors continue to promote legacy interfaces.

It’s probably not possible for Airtable to know this with any degree of precision because there are so many ways – some good, some crappy – to build external apps.

Ideally, Airtable has perfect knowledge about every use case and wackadoodle approach we have implemented to use Airtable content. But this is simply not possible. What we can ask for is a clear representation of the architecture and from that, everyone can make good assessments and expectations of performance as they seek new ways to abuse Airtable as an accidental back-end.

Actually I need to revise my statement. Airtable gave me a suggestion on how to revise the formula for extracting a url because the format of the url might change. So I did get feedback that the url format would change, but no indication that the url would potentially expire, would never be valid to begin with, or otherwise should not be used. So the left hand must have had some communication with the right hand. Just apparently not enough.

If urls from formula fields will produce never valid urls starting in November, this affects two of my apps that are already published, and another app currently in development. None of these apps need to use urls from formulas that have an extended shelf life, and only one sends that url outside the Airtable interface (where it is only used for a few seconds.)

You may very well say that I should re-write the app to get the url from the attachment itself instead of the formula. However, I want my users to be able to do things like provide a height and width to all the images in a single attachment field or wrap each url in different html tags based on the file type. I know how to do this with formula fields, but having to move this logic into my app in a way that is easy for my users is impossible.

Right, but I barely understand the very basics of what this change means. And we don’t even understand under what circumstances the URLs will expire, and when the URLs will expire. The very little information that has been provided so far doesn’t even allow me to tell my clients with confidence whether their solutions will break or not break.

In this case I was referring to a custom app using the blocks SDK, so the REST API isn’t involved. I suppose I might need to use a React hook, but I think that the hook would need to be written by Airtable. They probably have already solved it because it affects their own apps (especially Page Designer), but have not shared that info, and have possibly forgotten to consider that this affects third party app developers.

This information is what we are asking for. And by “we” I mean the top members of this community forum.

In the case of my apps, I do not consider my use of the urls as abuse or as an accidental back-end (although other people could use the urls obtained with help from my app in abusive ways).

In fact, one of my apps in development needs to use urls from formula fields and it never sends those urls outside of the app itself.

Neither do I. Internal apps should not be deeply affected by this change and I’m sure Airtable is working to ensure backward compatibility. In fact, for internal apps, there shouldn’t actually be the need for a CDN reference or any expiration. The Airtable client or proxies into Airtable data that run in the UI have a direct pipeline to these assets. It’s when you start casting content into the wild - this is where it will have the greatest impact.