Airtable dropping support for public attachments :bomb:
Airtable is dropping public url support for attachment in an upcoming update that will take place in Nov 2022.
This basically mean all urls to all attachments uploaded prior to that date will cease to work, and all attachments public leads uploaded from there will only work for a “few hours” (would be great to know exactly how long, by the way).
Supposedly being a security update, it’s more of a shitty update, speaking frankly. There are many other ways to achieve a similar result (where security is enforced) while doing it in a smart way that doesn’t hit all customers where it hurts.
This will break like all our current workflows using attachments, and makes the nice UI to upload file completely obsolete to us and all our users.
For instance, allowing to specify in the Attachment field whether to use a temporary link (and how long) would be so much simpler and effective.
So, my take is that Airtable does this on purpose, because this way it forces all end-users to use Airtable the way they intended to, through the UI, with a dedicated account.
But even those users will get hurt with this update.
Official email
On November 8, 2022, Airtable will improve the security of our attachment URLs by incorporating an expiring links functionality. Once this change takes place:
Any attachment URLs obtained via the public API and the CSV export functionality will expire after a few hours.
URLs obtained from copying an attachment cell value will open the file to the attachment viewer within the product, instead of directly opening the file.
The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid; the filename obtained in the same way will continue to work as expected.
Who is impacted?
Users who are storing attachment URLs anywhere directly outside of the Airtable product for persisting an attachment.
What is the reason for this change?
This change will make attachment URLs more secure to use in the Airtable product.
What do I need to do?
If you have workflows with attachment URLs that will be impacted, you can begin migrating them over to comply with the new functionality now by following the steps in this help article.
Additionally, on November 8, 2022 when secure attachment URLs launches, you’ll also have the opportunity to opt out of the migration for a 3 month period of time until we fully switch over on February 7, 2023.
Page 2 / 3
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.
They have telegraphed that any URL captured from an attachment field is good for about 2 hours. Based on that, all URLs are subject to this new limitation. This is how signed URLs work - they have an expiration date/time and this creates two key advantages - added security and disincentives to create alternative frontends that use Airtable as an accidental (or intentional) back-end server/webhost/free CDN.
I think this alone is enough data to demonstrate where the impact will be felt most.
They have telegraphed that any URL captured from an attachment field is good for about 2 hours. Based on that, all URLs are subject to this new limitation. This is how signed URLs work - they have an expiration date/time and this creates two key advantages - added security and disincentives to create alternative frontends that use Airtable as an accidental (or intentional) back-end server/webhost/free CDN.
I think this alone is enough data to demonstrate where the impact will be felt most.
We actually have no idea what it means for a “URL to be captured form an attachment field”, which is why we would need more clarification from Airtable and @Jordan_Scott1 on this, and why there is a significant amount of confusion on this topic.
The support article specifically mentions the API, so maybe this only affects REST API calls. For example, if a user just opens the attachment’s URL in a web browser, perhaps that behavior will not be affected at all.
Also, many people are concerned about copying & pasting the URL of an attachment into an email, and are unsure if clicking on that link will continue to work in the email AFTER a few hours have passed. Since a URL inserted into an email doesn’t use the REST API, it’s likely to assume that this scenario will CONTINUE to work in the future.
But again, the support article is so vague that I don’t think anybody can claim that they have full confidence on all the scenarios which may or may not be impacted by this.
We actually have no idea what it means for a “URL to be captured form an attachment field”, which is why we would need more clarification from Airtable and @Jordan_Scott1 on this, and why there is a significant amount of confusion on this topic.
The support article specifically mentions the API, so maybe this only affects REST API calls. For example, if a user just opens the attachment’s URL in a web browser, perhaps that behavior will not be affected at all.
Also, many people are concerned about copying & pasting the URL of an attachment into an email, and are unsure if clicking on that link will continue to work in the email AFTER a few hours have passed. Since a URL inserted into an email doesn’t use the REST API, it’s likely to assume that this scenario will CONTINUE to work in the future.
But again, the support article is so vague that I don’t think anybody can claim that they have full confidence on all the scenarios which may or may not be impacted by this.
Okay - basics -
API requests a record with an attachment.
Attachment has a URL.
API process captures that URL
API process embeds that URL into a web page or uses the URL to render said image.
Airtable changes the address of the URL 120 minutes later.
URL and rendered image that were “captured” and stored in the wild now fail.
Possibly. Certainly, any attachment URLs are likely to fail after the signed URL expires. But there are other cases where this could create problems such as an email message that used a fully no-code method to capture and store-forward an attachment address would likely fail after a short period of time.
I think you’re dreaming. How would Airtable force all emails sitting in inboxes to magically change to the latest signed URL for an attachment that was exposed yesterday (for example)? You can easily mimic this test -
Create an automated email.
Include two data values in the email; an attachment URL and a field value.
Send the email with these values.
Open the email, verify they work.
Delete the image in the attachment and replace it with a different image; replace the data value as well with a new value.
Open the email - see how it works now.
But let’s say that Airtable were able to find a way to proxy the expired URLs for the latest URLs to requests from a known source (such as an automation) - like a link that was embedded through an email process. Doing so, would simply re-open the ability for abuse.
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.
When you say should not be deeply affected are you speaking with actual knowledge of how it will work or are you stating what you think are reasonable expectations?
It also isn’t clear if Airtable thinks of third party marketplace apps as “internal apps” or not. The custom apps sdk currently only provides the same attachment url available in scripting, a formula field, and the REST api.
What do you think the custom apps sdk should provide for accessing attachments come November?
What do you think would be a reasonable timeline for Airtable to publish details on how the custom apps sdk is affected so that third party developers with apps already in the marketplace can adjust the apps and get through QA in time for their apps to continue working come November?
When you say should not be deeply affected are you speaking with actual knowledge of how it will work or are you stating what you think are reasonable expectations?
It also isn’t clear if Airtable thinks of third party marketplace apps as “internal apps” or not. The custom apps sdk currently only provides the same attachment url available in scripting, a formula field, and the REST api.
What do you think the custom apps sdk should provide for accessing attachments come November?
What do you think would be a reasonable timeline for Airtable to publish details on how the custom apps sdk is affected so that third party developers with apps already in the marketplace can adjust the apps and get through QA in time for their apps to continue working come November?
If I said …
… will not be deeply affected by this change
That would be direct knowledge of their architecture and plans. I used “should” because I’m uncertain and this seems like a reasonable expectation. Airtable has a duty to try to sustain backward compatibility.
Indeed, but it runs in the client, so there’s an expectation that whatever URLs are available to the client, they should always work. Ergo, it’s probably a safe bet that signed URLs will work just dandy in custom apps.
@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.
@ScottWorld working with the team on pulling this together!
I’d like to try to clarify a few things, as I see there is even more confusion here that I thought there would be.
For comprehension’s sake, I’ll consider a delay of 2h before the initial public link is changed/invalidated (I have no idea what will be the exact delay)
Airtable
What will not be affected:
Attachment fields within Airtable (seeing a CSV file, picture and modify them, within Airtable)
If all users use Airtable directly, they won’t be affected while using the Airtable UI
What will completely break:
Any usage based on a formula (e.g: pictureUrl) that gets the public URL of an attachment. This will work for 2h and then the public link will display a 404.
This is a very common use case and will be one of the most painful breaking changes (IMHO)
If you embed an Attachment (picture, pdf, csv) in an email, this will continue to work, because the attachment itself will have been copied and embedded
If you share the public link of an Attachment (picture, pdf, csv), this will only work for 2h, as the public link will then be invalid and return a 404
The formula pictureUrl will not be updated, it will become invalid/stale after 2h
Other examples
Sending a Slack message with a public link toward an attachment will only be valid for 2h
Using Integromat (Make)/Zapier for sending public URL toward an attachment will only be valid for 2h
Third parties
Now let’s look how will this affect third-parties tools such as Stacker, Noloco and Softr.
Those tools usually have a “cache” between Airtable and their customer-facing UI, we’ll consider they do. (Stacker and Noloco do for sure, I don’t know about Softr)
What will not be affected, or slightly affected:
Attachment fields (seeing a CSV file, picture and modify them, within the chosen tool)
Those tools fetch the Airtable records and will always get a valid public URL, because even if Airtable changes the public url every 2h, since those tools keep fetching the most recent data, they’ll keep receiving a valid public url
Unfortunately, those “refreshes” have delay. For Stacker, it can be up to 15mn. If the public URL changes every 2h, and Stacker updates its cache every 15mn, there will most likely be a “up to 15mn” window of time where the public link used by Stacker will have changed on Airtable but not reflected in their cache. Thus, displaying a broken image on Stacker UI. (same for Noloco and Softr, although their exact refresh delay might differ and cause more/less issues)
UPDATE: Noloco is not simply using a cache as I thought, but they actually store the attachments on their own server for a while, so they are not subject to the above issue as they’ll always display a working attachment, no matter how frequently Airtable invalidates public urls. Stacker also stated that change will not break their app.
What will completely break:
Displaying the public link of an attachment (coming from a Formula field) will only work for 2h
This is a very common use case and will be one of the most painful breaking changes (IMHO)
Airtable REST API
The API will not behave differently from the UI. If you fetch an Attachment field, the attached public URL will always be valid, until “Gods know when”, as we probably won’t know when the next public link auto-update will happen, which will invalidate the associated public link and will require a new fetch using the API to get the new correct value.
Using a Formula field like pictureUrl will only work for the first 2h, after what the link will be stale
So, what will really matter here is to use the public URL from the Attachment field, not from a Formula.
Static websites might break. This will break static websites that rely on the Attachments public urls, because they use those urls directly and usually don’t update them once the site has been published.
For example, websites built using Next.js (SSG without timeout) and similar technologies will cease to work properly at most 2h after the build, as all links to Attachments fields will have changed, if they don’t host their own version of the attachments.
Airtable automations
The automations themselves won’t break, but what they do might, depending on what’s being done.
When using Attachment fields, it should just keep working.
Sending a picture or document in an email (embedded), etc.
But, if you use an Airtable formula, the link will only be valid for the first 2h
Displaying a direct link to a picture or document
Potential solutions
The most viable solution is either not use Airtable attachments directly, or to mirror any Attachment to another system that will not invalidate the links.
If you’re using a 3rd party (Noloco, Stacker, Softr) that stores your data into Airtable, you might ask them to mirror the attachment to another provider while uploading it (store it elsewhere, and maybe store it into Airtable for backward compatibilty, too). In this case, you’d use the Airtable Attachment field as before, and the mirrored public link (stored outside of airtable) for all automation/integration related stuff.
Practical solution example
I’m in the same situation as most of you, I built a business that displays a logos and pdfs on static sites, to help students find financing solutions. All those links will break with this update, all logos and PDF links will cease to work. Also, we have Editors (customers) who use a Stacker app to manage/edit those records.
What I know I must do is:
Keep the Attachment fields as they used to be, to allow Editors to see/update them in their Stacker app (I don’t want to break their workflow)
Add a mirrored public url to those Attachments, stored in another provider (I might use the BuiltOnAir solution, or build my own App to deal with that, I don’t know yet how we’ll achieve that, exactly)
Use those links on our static websites, so that I can keep using Static websites
Auto-update those mirrored links when the Attachment itself is updated
With this, I’ll be able to keep my Editor workflow similar (although the displayed attachment will most likely fail every 2h due to the caching delay of Stacker), and keep our website built the same way.
My ideal solution would be to not use Airtable Attachments fields anymore, but only store the public url link in Airtable, but this will require important changes on Stacker/Noloco to handle that properly so that the Editors workflow is not badly affected by this change.
I hope it helps understand the whole issue, how you’ll be affected, and how you can remediate it.
I’d like to try to clarify a few things, as I see there is even more confusion here that I thought there would be.
For comprehension’s sake, I’ll consider a delay of 2h before the initial public link is changed/invalidated (I have no idea what will be the exact delay)
Airtable
What will not be affected:
Attachment fields within Airtable (seeing a CSV file, picture and modify them, within Airtable)
If all users use Airtable directly, they won’t be affected while using the Airtable UI
What will completely break:
Any usage based on a formula (e.g: pictureUrl) that gets the public URL of an attachment. This will work for 2h and then the public link will display a 404.
This is a very common use case and will be one of the most painful breaking changes (IMHO)
If you embed an Attachment (picture, pdf, csv) in an email, this will continue to work, because the attachment itself will have been copied and embedded
If you share the public link of an Attachment (picture, pdf, csv), this will only work for 2h, as the public link will then be invalid and return a 404
The formula pictureUrl will not be updated, it will become invalid/stale after 2h
Other examples
Sending a Slack message with a public link toward an attachment will only be valid for 2h
Using Integromat (Make)/Zapier for sending public URL toward an attachment will only be valid for 2h
Third parties
Now let’s look how will this affect third-parties tools such as Stacker, Noloco and Softr.
Those tools usually have a “cache” between Airtable and their customer-facing UI, we’ll consider they do. (Stacker and Noloco do for sure, I don’t know about Softr)
What will not be affected, or slightly affected:
Attachment fields (seeing a CSV file, picture and modify them, within the chosen tool)
Those tools fetch the Airtable records and will always get a valid public URL, because even if Airtable changes the public url every 2h, since those tools keep fetching the most recent data, they’ll keep receiving a valid public url
Unfortunately, those “refreshes” have delay. For Stacker, it can be up to 15mn. If the public URL changes every 2h, and Stacker updates its cache every 15mn, there will most likely be a “up to 15mn” window of time where the public link used by Stacker will have changed on Airtable but not reflected in their cache. Thus, displaying a broken image on Stacker UI. (same for Noloco and Softr, although their exact refresh delay might differ and cause more/less issues)
UPDATE: Noloco is not simply using a cache as I thought, but they actually store the attachments on their own server for a while, so they are not subject to the above issue as they’ll always display a working attachment, no matter how frequently Airtable invalidates public urls. Stacker also stated that change will not break their app.
What will completely break:
Displaying the public link of an attachment (coming from a Formula field) will only work for 2h
This is a very common use case and will be one of the most painful breaking changes (IMHO)
Airtable REST API
The API will not behave differently from the UI. If you fetch an Attachment field, the attached public URL will always be valid, until “Gods know when”, as we probably won’t know when the next public link auto-update will happen, which will invalidate the associated public link and will require a new fetch using the API to get the new correct value.
Using a Formula field like pictureUrl will only work for the first 2h, after what the link will be stale
So, what will really matter here is to use the public URL from the Attachment field, not from a Formula.
Static websites might break. This will break static websites that rely on the Attachments public urls, because they use those urls directly and usually don’t update them once the site has been published.
For example, websites built using Next.js (SSG without timeout) and similar technologies will cease to work properly at most 2h after the build, as all links to Attachments fields will have changed, if they don’t host their own version of the attachments.
Airtable automations
The automations themselves won’t break, but what they do might, depending on what’s being done.
When using Attachment fields, it should just keep working.
Sending a picture or document in an email (embedded), etc.
But, if you use an Airtable formula, the link will only be valid for the first 2h
Displaying a direct link to a picture or document
Potential solutions
The most viable solution is either not use Airtable attachments directly, or to mirror any Attachment to another system that will not invalidate the links.
If you’re using a 3rd party (Noloco, Stacker, Softr) that stores your data into Airtable, you might ask them to mirror the attachment to another provider while uploading it (store it elsewhere, and maybe store it into Airtable for backward compatibilty, too). In this case, you’d use the Airtable Attachment field as before, and the mirrored public link (stored outside of airtable) for all automation/integration related stuff.
Practical solution example
I’m in the same situation as most of you, I built a business that displays a logos and pdfs on static sites, to help students find financing solutions. All those links will break with this update, all logos and PDF links will cease to work. Also, we have Editors (customers) who use a Stacker app to manage/edit those records.
What I know I must do is:
Keep the Attachment fields as they used to be, to allow Editors to see/update them in their Stacker app (I don’t want to break their workflow)
Add a mirrored public url to those Attachments, stored in another provider (I might use the BuiltOnAir solution, or build my own App to deal with that, I don’t know yet how we’ll achieve that, exactly)
Use those links on our static websites, so that I can keep using Static websites
Auto-update those mirrored links when the Attachment itself is updated
With this, I’ll be able to keep my Editor workflow similar (although the displayed attachment will most likely fail every 2h due to the caching delay of Stacker), and keep our website built the same way.
My ideal solution would be to not use Airtable Attachments fields anymore, but only store the public url link in Airtable, but this will require important changes on Stacker/Noloco to handle that properly so that the Editors workflow is not badly affected by this change.
I hope it helps understand the whole issue, how you’ll be affected, and how you can remediate it.
I’ll update my previous post to take Noloco’s answer into consideration.
Thanks for sharing this, and for writing it. It’s great to let Airtable hear how people are actually going to be affected by this change.
Just to shine some more light on it from our side.
When you sync your base with Noloco, we actually don’t cache your data and files, we store it in our own database.
What that practically means is, when we get your Airtable attachment link (which will be valid when it comes from the API) we copy that file over to Noloco, so even if that link becomes invalid it doesn’t matter, because we have the original file.
The only change that might affect us, is how they display those attachments.
Currently (as you know) when you visit an attachment URL it display the file directly. I believe they’re going to be displaying the attachments in the UI (like a sharing link) after the change. We’ll have to figure out how to grab the file from there, but it shouldn’t be difficult.
I’d like to try to clarify a few things, as I see there is even more confusion here that I thought there would be.
For comprehension’s sake, I’ll consider a delay of 2h before the initial public link is changed/invalidated (I have no idea what will be the exact delay)
Airtable
What will not be affected:
Attachment fields within Airtable (seeing a CSV file, picture and modify them, within Airtable)
If all users use Airtable directly, they won’t be affected while using the Airtable UI
What will completely break:
Any usage based on a formula (e.g: pictureUrl) that gets the public URL of an attachment. This will work for 2h and then the public link will display a 404.
This is a very common use case and will be one of the most painful breaking changes (IMHO)
If you embed an Attachment (picture, pdf, csv) in an email, this will continue to work, because the attachment itself will have been copied and embedded
If you share the public link of an Attachment (picture, pdf, csv), this will only work for 2h, as the public link will then be invalid and return a 404
The formula pictureUrl will not be updated, it will become invalid/stale after 2h
Other examples
Sending a Slack message with a public link toward an attachment will only be valid for 2h
Using Integromat (Make)/Zapier for sending public URL toward an attachment will only be valid for 2h
Third parties
Now let’s look how will this affect third-parties tools such as Stacker, Noloco and Softr.
Those tools usually have a “cache” between Airtable and their customer-facing UI, we’ll consider they do. (Stacker and Noloco do for sure, I don’t know about Softr)
What will not be affected, or slightly affected:
Attachment fields (seeing a CSV file, picture and modify them, within the chosen tool)
Those tools fetch the Airtable records and will always get a valid public URL, because even if Airtable changes the public url every 2h, since those tools keep fetching the most recent data, they’ll keep receiving a valid public url
Unfortunately, those “refreshes” have delay. For Stacker, it can be up to 15mn. If the public URL changes every 2h, and Stacker updates its cache every 15mn, there will most likely be a “up to 15mn” window of time where the public link used by Stacker will have changed on Airtable but not reflected in their cache. Thus, displaying a broken image on Stacker UI. (same for Noloco and Softr, although their exact refresh delay might differ and cause more/less issues)
UPDATE: Noloco is not simply using a cache as I thought, but they actually store the attachments on their own server for a while, so they are not subject to the above issue as they’ll always display a working attachment, no matter how frequently Airtable invalidates public urls. Stacker also stated that change will not break their app.
What will completely break:
Displaying the public link of an attachment (coming from a Formula field) will only work for 2h
This is a very common use case and will be one of the most painful breaking changes (IMHO)
Airtable REST API
The API will not behave differently from the UI. If you fetch an Attachment field, the attached public URL will always be valid, until “Gods know when”, as we probably won’t know when the next public link auto-update will happen, which will invalidate the associated public link and will require a new fetch using the API to get the new correct value.
Using a Formula field like pictureUrl will only work for the first 2h, after what the link will be stale
So, what will really matter here is to use the public URL from the Attachment field, not from a Formula.
Static websites might break. This will break static websites that rely on the Attachments public urls, because they use those urls directly and usually don’t update them once the site has been published.
For example, websites built using Next.js (SSG without timeout) and similar technologies will cease to work properly at most 2h after the build, as all links to Attachments fields will have changed, if they don’t host their own version of the attachments.
Airtable automations
The automations themselves won’t break, but what they do might, depending on what’s being done.
When using Attachment fields, it should just keep working.
Sending a picture or document in an email (embedded), etc.
But, if you use an Airtable formula, the link will only be valid for the first 2h
Displaying a direct link to a picture or document
Potential solutions
The most viable solution is either not use Airtable attachments directly, or to mirror any Attachment to another system that will not invalidate the links.
If you’re using a 3rd party (Noloco, Stacker, Softr) that stores your data into Airtable, you might ask them to mirror the attachment to another provider while uploading it (store it elsewhere, and maybe store it into Airtable for backward compatibilty, too). In this case, you’d use the Airtable Attachment field as before, and the mirrored public link (stored outside of airtable) for all automation/integration related stuff.
Practical solution example
I’m in the same situation as most of you, I built a business that displays a logos and pdfs on static sites, to help students find financing solutions. All those links will break with this update, all logos and PDF links will cease to work. Also, we have Editors (customers) who use a Stacker app to manage/edit those records.
What I know I must do is:
Keep the Attachment fields as they used to be, to allow Editors to see/update them in their Stacker app (I don’t want to break their workflow)
Add a mirrored public url to those Attachments, stored in another provider (I might use the BuiltOnAir solution, or build my own App to deal with that, I don’t know yet how we’ll achieve that, exactly)
Use those links on our static websites, so that I can keep using Static websites
Auto-update those mirrored links when the Attachment itself is updated
With this, I’ll be able to keep my Editor workflow similar (although the displayed attachment will most likely fail every 2h due to the caching delay of Stacker), and keep our website built the same way.
My ideal solution would be to not use Airtable Attachments fields anymore, but only store the public url link in Airtable, but this will require important changes on Stacker/Noloco to handle that properly so that the Editors workflow is not badly affected by this change.
I hope it helps understand the whole issue, how you’ll be affected, and how you can remediate it.
Can you please cite where Airtable states that urls from formula fields will work for two hours and then fail? I find the wording “become invalid” (versus “expire”) to be ambiguous.
Can you please cite where Airtable states that urls from formula fields will work for two hours and then fail? I find the wording “become invalid” (versus “expire”) to be ambiguous.
The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid. The filename obtained in the same way will continue to work as expected.
Airtable also use “invalid” term, by it I mean “expires”.
The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid. The filename obtained in the same way will continue to work as expected.
Airtable also use “invalid” term, by it I mean “expires”.
And I think this verbiage is ambiguous. Why switch terms from “expire” to “invalid” unless something different is happening. I also did not see the term “invalid” used for other methods of obtaining urls.
Another interpretation of the wording is that formula fields with attachments will continue to use the same format (comma separated list of file names followed by the url in parentheses) so that people can continue to extract file names with formulas. However the actual urls will retain their September values in November, but cease to work at all.
There are also several technical issues if urls for formula field will work for a few hours and then expire.
While I appreciate your efforts to clarify the changes, I still feel that this extra clarity needs to come from Airtable directly.
Exactly, everybody is just making educated guesses at this point. Nobody really knows anything until Airtable clarifies everything for us, which Jordan said that they are going to do soon.
The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid. The filename obtained in the same way will continue to work as expected.
Airtable also use “invalid” term, by it I mean “expires”.
LOL This is really starting to get fun. Okay - so - whoever crafted this text made a big mistake and that mistake is a conflation of negatives and positives. The only rational interpretation is:
Formula fields are always recalculating; this we know.
Any formula based on attributes of an attachment field will currently update just fine if they change; this we also know.
For any sort of rational compatibility going forward, formula fields must continue to reflect the ground truth of the attachment field attributes; recalculation is likely the pathway to achieve this.
Attachment field names and URLs already change (from time-to-time) and formula fields based on them update just fine when they do; this we know beyond a shadow of a doubt.
Attachment URLs that are influenced by the new rules for invalidation are likely to simply recalculate no differently than they do today.
If we’re confident that #1 through #4 represents true interpretations of the current system, #5 is the most probable outcome. Despite what the documentation says, the writer probably intended to say exactly what #3 through #5 say in far fewer words. :winking_face:
I predict (and will bet a fine turkey sandwich) that this will be proven wrong. The entire premise of a formula field is based on its internal awareness to recalculate when references to other fields change. The links will never be stale. In fact, I also predict and will happily place side bets for mac-n-cheese that no links inside the Airtable UI will ever be stale unless they were placed there by scripts that unsuspectingly froze them in time as static values.
And I think this verbiage is ambiguous. Why switch terms from “expire” to “invalid” unless something different is happening. I also did not see the term “invalid” used for other methods of obtaining urls.
Another interpretation of the wording is that formula fields with attachments will continue to use the same format (comma separated list of file names followed by the url in parentheses) so that people can continue to extract file names with formulas. However the actual urls will retain their September values in November, but cease to work at all.
There are also several technical issues if urls for formula field will work for a few hours and then expire.
While I appreciate your efforts to clarify the changes, I still feel that this extra clarity needs to come from Airtable directly.
I also agree that the wording concerning formula fields and attachment URLs is extremely ambiguous and conflicting. And as you make clear - both of these scenarios are breaking changes that the universe of users could never tolerate, so I think it’s fiction. We’re all in a froth for absolutely no reason whatsoever. Major issues with this CDN-related change abound, but this is not one that even rises to the top 20 issues.
I’d like to try to clarify a few things, as I see there is even more confusion here that I thought there would be.
For comprehension’s sake, I’ll consider a delay of 2h before the initial public link is changed/invalidated (I have no idea what will be the exact delay)
Airtable
What will not be affected:
Attachment fields within Airtable (seeing a CSV file, picture and modify them, within Airtable)
If all users use Airtable directly, they won’t be affected while using the Airtable UI
What will completely break:
Any usage based on a formula (e.g: pictureUrl) that gets the public URL of an attachment. This will work for 2h and then the public link will display a 404.
This is a very common use case and will be one of the most painful breaking changes (IMHO)
If you embed an Attachment (picture, pdf, csv) in an email, this will continue to work, because the attachment itself will have been copied and embedded
If you share the public link of an Attachment (picture, pdf, csv), this will only work for 2h, as the public link will then be invalid and return a 404
The formula pictureUrl will not be updated, it will become invalid/stale after 2h
Other examples
Sending a Slack message with a public link toward an attachment will only be valid for 2h
Using Integromat (Make)/Zapier for sending public URL toward an attachment will only be valid for 2h
Third parties
Now let’s look how will this affect third-parties tools such as Stacker, Noloco and Softr.
Those tools usually have a “cache” between Airtable and their customer-facing UI, we’ll consider they do. (Stacker and Noloco do for sure, I don’t know about Softr)
What will not be affected, or slightly affected:
Attachment fields (seeing a CSV file, picture and modify them, within the chosen tool)
Those tools fetch the Airtable records and will always get a valid public URL, because even if Airtable changes the public url every 2h, since those tools keep fetching the most recent data, they’ll keep receiving a valid public url
Unfortunately, those “refreshes” have delay. For Stacker, it can be up to 15mn. If the public URL changes every 2h, and Stacker updates its cache every 15mn, there will most likely be a “up to 15mn” window of time where the public link used by Stacker will have changed on Airtable but not reflected in their cache. Thus, displaying a broken image on Stacker UI. (same for Noloco and Softr, although their exact refresh delay might differ and cause more/less issues)
UPDATE: Noloco is not simply using a cache as I thought, but they actually store the attachments on their own server for a while, so they are not subject to the above issue as they’ll always display a working attachment, no matter how frequently Airtable invalidates public urls. Stacker also stated that change will not break their app.
What will completely break:
Displaying the public link of an attachment (coming from a Formula field) will only work for 2h
This is a very common use case and will be one of the most painful breaking changes (IMHO)
Airtable REST API
The API will not behave differently from the UI. If you fetch an Attachment field, the attached public URL will always be valid, until “Gods know when”, as we probably won’t know when the next public link auto-update will happen, which will invalidate the associated public link and will require a new fetch using the API to get the new correct value.
Using a Formula field like pictureUrl will only work for the first 2h, after what the link will be stale
So, what will really matter here is to use the public URL from the Attachment field, not from a Formula.
Static websites might break. This will break static websites that rely on the Attachments public urls, because they use those urls directly and usually don’t update them once the site has been published.
For example, websites built using Next.js (SSG without timeout) and similar technologies will cease to work properly at most 2h after the build, as all links to Attachments fields will have changed, if they don’t host their own version of the attachments.
Airtable automations
The automations themselves won’t break, but what they do might, depending on what’s being done.
When using Attachment fields, it should just keep working.
Sending a picture or document in an email (embedded), etc.
But, if you use an Airtable formula, the link will only be valid for the first 2h
Displaying a direct link to a picture or document
Potential solutions
The most viable solution is either not use Airtable attachments directly, or to mirror any Attachment to another system that will not invalidate the links.
If you’re using a 3rd party (Noloco, Stacker, Softr) that stores your data into Airtable, you might ask them to mirror the attachment to another provider while uploading it (store it elsewhere, and maybe store it into Airtable for backward compatibilty, too). In this case, you’d use the Airtable Attachment field as before, and the mirrored public link (stored outside of airtable) for all automation/integration related stuff.
Practical solution example
I’m in the same situation as most of you, I built a business that displays a logos and pdfs on static sites, to help students find financing solutions. All those links will break with this update, all logos and PDF links will cease to work. Also, we have Editors (customers) who use a Stacker app to manage/edit those records.
What I know I must do is:
Keep the Attachment fields as they used to be, to allow Editors to see/update them in their Stacker app (I don’t want to break their workflow)
Add a mirrored public url to those Attachments, stored in another provider (I might use the BuiltOnAir solution, or build my own App to deal with that, I don’t know yet how we’ll achieve that, exactly)
Use those links on our static websites, so that I can keep using Static websites
Auto-update those mirrored links when the Attachment itself is updated
With this, I’ll be able to keep my Editor workflow similar (although the displayed attachment will most likely fail every 2h due to the caching delay of Stacker), and keep our website built the same way.
My ideal solution would be to not use Airtable Attachments fields anymore, but only store the public url link in Airtable, but this will require important changes on Stacker/Noloco to handle that properly so that the Editors workflow is not badly affected by this change.
I hope it helps understand the whole issue, how you’ll be affected, and how you can remediate it.
Like @kuovonne, I appreciate the depth of your comments, however, I think you used a very broad brush stroke that creates uncertainty that may also be misinterpreted.
Let’s start with the term “custom apps” which is known in Airtable circles to represent React apps that run as plugins to the Airtable framework. In my view, custom apps are the one place where exactly the opposite will occur - 100% of them will continue to function because they are indigenous to the Airtable UI and the Airtable UI does not have the luxury of utilizing invalid (or expired) URLs. This would be a vast breaking change and while I sometimes have trepidation about development choices at Airtable, I am willing to bet lots of fine sandwiches that the custom app realm is on safe ground.
Perhaps. But not in every case, and hardly “completely”. Imagine a Wordpress site that was built with data from Airtable as a “snapshot in time” - i.e., static web content. It has a cache for such things like images and other app assets and resources. Typically, just referencing an image will cause the web service to cache the image at the server much the way your browser does this for performance reasons. When a page loads, if the server is unable to resolve the link to the image or determine it has indeed changed with a conditional GET, it will render what it has in the cache. There are plugins and all sorts of features that developers can apply to sustain a business-as-usual outcome in the face of this Airtable policy change.
Because there are so many ways to implement server-side web caching – much of it already in place by default – you cannot assume every instance of static web content will fail. It may certainly be out of date - but we know that going in - it’s a static site. Suggesting that all sites built like this will be broken is an overreach and sensationalizing the issue.
LOL This is really starting to get fun. Okay - so - whoever crafted this text made a big mistake and that mistake is a conflation of negatives and positives. The only rational interpretation is:
Formula fields are always recalculating; this we know.
Any formula based on attributes of an attachment field will currently update just fine if they change; this we also know.
For any sort of rational compatibility going forward, formula fields must continue to reflect the ground truth of the attachment field attributes; recalculation is likely the pathway to achieve this.
Attachment field names and URLs already change (from time-to-time) and formula fields based on them update just fine when they do; this we know beyond a shadow of a doubt.
Attachment URLs that are influenced by the new rules for invalidation are likely to simply recalculate no differently than they do today.
If we’re confident that #1 through #4 represents true interpretations of the current system, #5 is the most probable outcome. Despite what the documentation says, the writer probably intended to say exactly what #3 through #5 say in far fewer words. :winking_face:
I predict (and will bet a fine turkey sandwich) that this will be proven wrong. The entire premise of a formula field is based on its internal awareness to recalculate when references to other fields change. The links will never be stale. In fact, I also predict and will happily place side bets for mac-n-cheese that no links inside the Airtable UI will ever be stale unless they were placed there by scripts that unsuspectingly froze them in time as static values.
In the past the formula result for an attachment only changed due to two factors: as part of the initial upload process, or when the filename was changed (either by the user or via code). While slightly confusing, the changing value due to the upload process was very brief and likely unnoticed by most users. The second change could be predicted by the user, and changed the filename only, not the url.
Currently the only formula fields that change values without a change to the underlying data is when a formula field used TODAY() or NOW(). While the frequency of updates to those formula functions have their own issues, at least their updating without a change to underlying data makes sense. Further, I cannot recall the exact sources, but I recall there was a test that showed that heavy use of calculated fields slows down REST API calls that create or update data, and heavy use TODAY() and NOW() also adds to the computation load of a base more so than other formula functions.
What you are suggesting is that formula fields based on attachments will now change even when the underlying data does not change. Also, there may be performance impacts due to these formula fields constantly recalculating.
Thank you.
I’m not one to speculate on the likelihood of a particular scenario. Mostly I was pointing out that it was a potential interpretation of ambiguous wording. I will try to wait patiently for official clarification.
I’m very tempted to take you up on that offer. I don’t think that the impact to custom apps will be large, but I believe that there will be an impact and potential code changes to custom apps to support this change.
Even with server-side caching (which I think you overestimate for static sites), the server-side cache will expire, thus breaking the static site.
In the past the formula result for an attachment only changed due to two factors: as part of the initial upload process, or when the filename was changed (either by the user or via code). While slightly confusing, the changing value due to the upload process was very brief and likely unnoticed by most users. The second change could be predicted by the user, and changed the filename only, not the url.
Currently the only formula fields that change values without a change to the underlying data is when a formula field used TODAY() or NOW(). While the frequency of updates to those formula functions have their own issues, at least their updating without a change to underlying data makes sense. Further, I cannot recall the exact sources, but I recall there was a test that showed that heavy use of calculated fields slows down REST API calls that create or update data, and heavy use TODAY() and NOW() also adds to the computation load of a base more so than other formula functions.
What you are suggesting is that formula fields based on attachments will now change even when the underlying data does not change. Also, there may be performance impacts due to these formula fields constantly recalculating.
Thank you.
I’m not one to speculate on the likelihood of a particular scenario. Mostly I was pointing out that it was a potential interpretation of ambiguous wording. I will try to wait patiently for official clarification.
I’m very tempted to take you up on that offer. I don’t think that the impact to custom apps will be large, but I believe that there will be an impact and potential code changes to custom apps to support this change.
Even with server-side caching (which I think you overestimate for static sites), the server-side cache will expire, thus breaking the static site.
Actually, I am predicting they must now change, otherwise, they would have to consider no support for attachment field URLs in formula fields.
The exclusion involves cases where apps capture URLs and sustain them separately and apart from the database itself. If you are making copies of CDN values (a decidedly bad idea to begin with), there will be an impact on custom apps. But given the nature of a custom app and the tight coupling with the Airtable UI and the data, what requirement would cause such a need to preserve a potentially dated value for anything - even normal data fields?
You are right - when the cache expires, the server is obligated to reach out to the original location. However, when that fails, most web servers can be configured to gracefully lean on the cache and give it another timed cycle. Web servers are pretty smart little beasts and if you don’t take advantage of these concepts, you are creating a recipe for disappointed visitors. My point is that it’s impossible to say all static websites based on Airtable data will fail.
Yeah, you’re right, one cannot predict all custom apps will fail indeed. I only considered the small world of static sites where there is no dedicated hosting of attachment and thus relying on those Airtable public urls.
Also, the term “custom apps” was poorly chosen, I didn’t mean “Apps/Blocks”, but real apps that live completely outside of Airtable and are made of custom code, no matter what programming language is chosen.
I predict (and will bet a fine turkey sandwich) that this will be proven wrong. The entire premise of a formula field is based on its internal awareness to recalculate when references to other fields change. The links will never be stale. In fact, I also predict and will happily place side bets for mac-n-cheese that no links inside the Airtable UI will ever be stale unless they were placed there by scripts that unsuspectingly froze them in time as static values.
You seem fairly confident in this, I am not. It’s not technically impossible for them to make an exception to this particular case. Yes, it would be a behavior we’ve never seen from a formula, but considering how much additional computation would be required for formulas to stay up-to-date, this is a sound decision.
Edit : I’ve updated the post to lift some confusion, thanks for the feedback.
Hi all -
My name is Al and I’m on the ecosystem team here at Airtable. I wanted to jump in and say thank you for sharing your feedback with us on this topic. We’ve updated our FAQ documentation based on the conversation here to answer many of the common questions we’ve seen so far.
We also wanted to share some insights into how we’re thinking about this change. While Airtable is used for many things, it was not designed to be a cloud-storage solution that specializes in file hosting, permissions, and sharing (other tools such as Box, Dropbox, or Google Drive, may be able to better accommodate your hosting needs). In the last few months, we heard feedback from customers that there is a need to enforce more robust security standards to ensure that only authorized Airtable users can view attachments. Our team is continually focused on making sure that Airtable is as secure as possible, and we made this change because we believe it will provide additional security measures for your teams.
We understand there are some cases where this change can cause friction or disrupt your workflow. First, we apologize for the inconvenience. Second, we’ve summarized answers to some questions we’ve received below to help give you clarity on exactly what this change entails and are happy to answer any additional questions you have about this change. You can also find our support documentation with additional FAQ’s about this feature here.
How does this impact automations?
We will add the ability for users to select whether they want a viewer URL that points to an attachment for logged-in users to view, or if they want an expiring URL for downloads. Most automations will continue to work without modifications. Specifically, the send email action is not impacted by this change. Automations that use URLs in freeform text fields (like a send slack message automation) will default to using the viewer URL.
How is uploading an attachment via URL different than downloads?
This change applies only to attachment downloads, not uploads. You will still be able to upload attachments using URLs after this change is live.
Does this impact thumbnail URLs?
This change also applies to thumbnail URLs. Once created, they will expire after a period of time.
How is this different than shared views?
All shared views, including forms, will remain as is and aren’t impacted by this change. This change specifically concerns attachment URLs. These look like “https://dl.airtable.com/…” Shared views could be a great solution for workflows that rely on sharing attachment URLs today.
How does this impact APIs?
APIs will return expiring download URLs rather than permanent URLs, for attachments and attachment thumbnails.
If I copy & paste the URL of an attachment into an email, will clicking on that link continue to work in the email AFTER a few hours have passed?
Today, if you copy & paste an attachment cell from a grid view, you will receive a permanent attachment URL. Since these are going away, copy & paste is being updated to use attachment viewer URLs - these require that the person accessing the URL be logged in to Airtable and have permissions to view the base.
How does this impact custom apps? For example URL’s in formula fields
All Apps produced by Airtable will be compatible with this change. Most third party apps will also work without changes. We will provide guidance to developers of third party apps on how to ensure compatibility, however, we cannot guarantee that all custom apps will be updated before this change is live.
How many hours will the URLs remain active before expiring?
URLs will remain active for 2 hours before expiring.
Hi all -
My name is Al and I’m on the ecosystem team here at Airtable. I wanted to jump in and say thank you for sharing your feedback with us on this topic. We’ve updated our FAQ documentation based on the conversation here to answer many of the common questions we’ve seen so far.
We also wanted to share some insights into how we’re thinking about this change. While Airtable is used for many things, it was not designed to be a cloud-storage solution that specializes in file hosting, permissions, and sharing (other tools such as Box, Dropbox, or Google Drive, may be able to better accommodate your hosting needs). In the last few months, we heard feedback from customers that there is a need to enforce more robust security standards to ensure that only authorized Airtable users can view attachments. Our team is continually focused on making sure that Airtable is as secure as possible, and we made this change because we believe it will provide additional security measures for your teams.
We understand there are some cases where this change can cause friction or disrupt your workflow. First, we apologize for the inconvenience. Second, we’ve summarized answers to some questions we’ve received below to help give you clarity on exactly what this change entails and are happy to answer any additional questions you have about this change. You can also find our support documentation with additional FAQ’s about this feature here.
How does this impact automations?
We will add the ability for users to select whether they want a viewer URL that points to an attachment for logged-in users to view, or if they want an expiring URL for downloads. Most automations will continue to work without modifications. Specifically, the send email action is not impacted by this change. Automations that use URLs in freeform text fields (like a send slack message automation) will default to using the viewer URL.
How is uploading an attachment via URL different than downloads?
This change applies only to attachment downloads, not uploads. You will still be able to upload attachments using URLs after this change is live.
Does this impact thumbnail URLs?
This change also applies to thumbnail URLs. Once created, they will expire after a period of time.
How is this different than shared views?
All shared views, including forms, will remain as is and aren’t impacted by this change. This change specifically concerns attachment URLs. These look like “https://dl.airtable.com/…” Shared views could be a great solution for workflows that rely on sharing attachment URLs today.
How does this impact APIs?
APIs will return expiring download URLs rather than permanent URLs, for attachments and attachment thumbnails.
If I copy & paste the URL of an attachment into an email, will clicking on that link continue to work in the email AFTER a few hours have passed?
Today, if you copy & paste an attachment cell from a grid view, you will receive a permanent attachment URL. Since these are going away, copy & paste is being updated to use attachment viewer URLs - these require that the person accessing the URL be logged in to Airtable and have permissions to view the base.
How does this impact custom apps? For example URL’s in formula fields
All Apps produced by Airtable will be compatible with this change. Most third party apps will also work without changes. We will provide guidance to developers of third party apps on how to ensure compatibility, however, we cannot guarantee that all custom apps will be updated before this change is live.
How many hours will the URLs remain active before expiring?
URLs will remain active for 2 hours before expiring.
non-expiring “viewer” urls that require a logged in collaborator
expiring urls that are good for a minimum of 2 hours and reach the raw file
invalid urls obtained from formula fields that will not work at all
Methods of getting urls:
Copying an attachment field (CMD+C, or CTRL+C) => viewer url
Native Airtable Automations => choice of “viewer” or expiring url
3rd party integration tools such as Zapier or Make.com => choice of “viewer” or expiring url
CSV Export => expiring urls
REST API (which most portals use) => expiring urls, including thumbnail urls
Scripting getCellValue() => expiring urls, including thumbnail urls
Scripting getCellValueAsString() => invalid url to match formula value
Custom Apps SDK => same as scripting
urls from using “developer tools” of a web browser => expiring urls
Using an attachment field in a formula field => invalid url that never works
Questions:
If 3rd party integration tools will have a choice of urls, will those tools need reconfiguring to specify which url to use or will existing zaps/scenarios be automatically migrated?
Will scripting be given a choice of which type of url to use?
A bunch of other questions relating to custom apps that can wait to be answered in some other venue.
Hi all -
My name is Al and I’m on the ecosystem team here at Airtable. I wanted to jump in and say thank you for sharing your feedback with us on this topic. We’ve updated our FAQ documentation based on the conversation here to answer many of the common questions we’ve seen so far.
We also wanted to share some insights into how we’re thinking about this change. While Airtable is used for many things, it was not designed to be a cloud-storage solution that specializes in file hosting, permissions, and sharing (other tools such as Box, Dropbox, or Google Drive, may be able to better accommodate your hosting needs). In the last few months, we heard feedback from customers that there is a need to enforce more robust security standards to ensure that only authorized Airtable users can view attachments. Our team is continually focused on making sure that Airtable is as secure as possible, and we made this change because we believe it will provide additional security measures for your teams.
We understand there are some cases where this change can cause friction or disrupt your workflow. First, we apologize for the inconvenience. Second, we’ve summarized answers to some questions we’ve received below to help give you clarity on exactly what this change entails and are happy to answer any additional questions you have about this change. You can also find our support documentation with additional FAQ’s about this feature here.
How does this impact automations?
We will add the ability for users to select whether they want a viewer URL that points to an attachment for logged-in users to view, or if they want an expiring URL for downloads. Most automations will continue to work without modifications. Specifically, the send email action is not impacted by this change. Automations that use URLs in freeform text fields (like a send slack message automation) will default to using the viewer URL.
How is uploading an attachment via URL different than downloads?
This change applies only to attachment downloads, not uploads. You will still be able to upload attachments using URLs after this change is live.
Does this impact thumbnail URLs?
This change also applies to thumbnail URLs. Once created, they will expire after a period of time.
How is this different than shared views?
All shared views, including forms, will remain as is and aren’t impacted by this change. This change specifically concerns attachment URLs. These look like “https://dl.airtable.com/…” Shared views could be a great solution for workflows that rely on sharing attachment URLs today.
How does this impact APIs?
APIs will return expiring download URLs rather than permanent URLs, for attachments and attachment thumbnails.
If I copy & paste the URL of an attachment into an email, will clicking on that link continue to work in the email AFTER a few hours have passed?
Today, if you copy & paste an attachment cell from a grid view, you will receive a permanent attachment URL. Since these are going away, copy & paste is being updated to use attachment viewer URLs - these require that the person accessing the URL be logged in to Airtable and have permissions to view the base.
How does this impact custom apps? For example URL’s in formula fields
All Apps produced by Airtable will be compatible with this change. Most third party apps will also work without changes. We will provide guidance to developers of third party apps on how to ensure compatibility, however, we cannot guarantee that all custom apps will be updated before this change is live.
How many hours will the URLs remain active before expiring?
URLs will remain active for 2 hours before expiring.
Hi AI, thanks for sharing your feedback, I have a few questions.
How does this impact custom apps? For example URL’s in formula fields
You don’t actually mention how formulas will be affected. My understanding is that they will not update and thus will contain a valid link only for the 2 first hours, is that correct?
How does this impact APIs?
The Stacker team told me Airtable told them that the API will return Attachment links that will not expire before at least one hour. I believe there is some confusion about that, so I’d like to be crystal clear:
Will you disable the previous public url of an attachment at the same time that you’ll make a new one available? Or will there be several public urls alive at the same time for the same attachment?
For the record, I am one of the users who have requested some change about attachment security, that was 2 years ago. But I’m really not satisfied on how it’s implemented. It would have been much more effective to keep the current behavior while allowing us to specify which attachments should be protected, and how often to perform a public url change.
Not everything contains sensitive information, and it’s unfortunate that things like logo or cover images will become publicly unusable.
Might I suggest reviewing that choice and make this change happens at a slower pace?
For instance, by granting us the ability to choose which attachments to protect, instead of applying it to all, that would give enough time for the community to adapt and build new tools (like auto-synching attachments to a CDN, etc.) and only apply that change to all attachments 6-12 months after that first change? It would definitely give me more confidence in our ability to adapt to that change.
Once again, I am highly disappointed with the “scorched earth” method that Airtable has taken in this situation.
Once again, I am highly disappointed with the “scorched earth” method that Airtable has taken in this situation.
My disappointment is slightly different. I recognize that there are important security and engineering issues that we are not privy to.
I am disappointed that Airtable does not appear to have realized how much confusion this announcement would sow. What if, before the announcement, Airtable contacted well known consultants and 3rd party developers in advanced, placed them under NDA, and asked them what are the key concerns and confusions that people will have? Then Airtable could use that information to craft clearer messages. There would be less speculation on what would or would not break, and people could focus on adapting things that will break.
My disappointment is slightly different. I recognize that there are important security and engineering issues that we are not privy to.
I am disappointed that Airtable does not appear to have realized how much confusion this announcement would sow. What if, before the announcement, Airtable contacted well known consultants and 3rd party developers in advanced, placed them under NDA, and asked them what are the key concerns and confusions that people will have? Then Airtable could use that information to craft clearer messages. There would be less speculation on what would or would not break, and people could focus on adapting things that will break.
I thought that 2022 was the year that they promised better communication with us? :man_shrugging:t2:
Maybe they meant 2023.
Years can get confusing — they all start with “20” these days. :winking_face:
non-expiring “viewer” urls that require a logged in collaborator
expiring urls that are good for a minimum of 2 hours and reach the raw file
invalid urls obtained from formula fields that will not work at all
Methods of getting urls:
Copying an attachment field (CMD+C, or CTRL+C) => viewer url
Native Airtable Automations => choice of “viewer” or expiring url
3rd party integration tools such as Zapier or Make.com => choice of “viewer” or expiring url
CSV Export => expiring urls
REST API (which most portals use) => expiring urls, including thumbnail urls
Scripting getCellValue() => expiring urls, including thumbnail urls
Scripting getCellValueAsString() => invalid url to match formula value
Custom Apps SDK => same as scripting
urls from using “developer tools” of a web browser => expiring urls
Using an attachment field in a formula field => invalid url that never works
Questions:
If 3rd party integration tools will have a choice of urls, will those tools need reconfiguring to specify which url to use or will existing zaps/scenarios be automatically migrated?
Will scripting be given a choice of which type of url to use?
A bunch of other questions relating to custom apps that can wait to be answered in some other venue.
Hi Kuovonne,
Your categories of URLs are correct. In regards to your methods of getting URLs:
3rd party integration tools such as Zapier or Make.com will get an expiring URL (clarification is that there won’t be the choice of “viewer”)
Scripting getCellValueAsString() will result in an expiring URL
To answer your questions:
3rd party integrations leveraging the API will have expiring URLs and will need to be migrated manually
For automation scripts, the existing URL will be an attachment viewer URL. We plan to add a new property to support expiring URLs.
We will be updating our support documentation soon with details about custom app implications with the attachment URL update
Airtable is dropping public url support for attachment in an upcoming update that will take place in Nov 2022.
This is a very common use case and will be one of the most painful breaking changes (IMHO)
UPDATE: Noloco is not simply using a cache as I thought, but they actually store the attachments on their own server for a while, so they are not subject to the above issue as they’ll always display a working attachment, no matter how frequently Airtable invalidates public urls. Stacker also stated that change will not break their app.