Skip to main content

: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. :money_mouth_face:

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.

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.


Hi Ambroise,

Thanks for your follow-up questions and feedback. To answer your question:

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?

There will be several public URLs alive at the same time. We will guarantee that a URL will not expire within 2 hours of receiving it, so if a user wants to refresh their URLs every hour, they will always have a working URL.

In regards to your last point about the timing of the rollout, we plan to offer a temporary opt-out period so that you or your organization has additional time to plan for the change. Details on this opt-out process will be shared closer to the November rollout.

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

Thank you for this update!

I’m confused. Will scripting app and automation scripts get different results? Or will getCellValue and getCellValueAsString get different results?

For what it’s worth, I think getCellValue should get the expiring url of the raw under the url property for the best backward compatibly with existing scripts (both in scripting app and automation scripts). For example, I have written several scripts that parse the contents of a plain text attachment that that would break if the url were suddenly a viewer url instead of the raw file. The script would not break with an expiring url.

A new property of viewerUrl could be added, so that scripting could access both.

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

Since my categories of URLs are correct, I suggest a change to the wording on the support documentation. The support page currently says

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.

I suggest the following revision:

The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid on November 8, 2022. The filename obtained in the same way will continue to work as expected.

Or if you want completely different wording:

When an attachment field is used in a formula field, the result will continue to include both the filename and a url for backward compatibility considerations. Filenames extracted in this manner will continue to work as expected. However, the urls will be invalid starting November 8, 2022, and accessing these urls after that date will result in an error code.

Anyone who has been using Airtable as a CDN for attachment images will need to move those images to a proper CDN service, and store the image url in Airtable instead. There are various techniques for moving those attachments to a CDN service. But how do you preview those images in Airtable when you now have only the url? You can click the url for the image, but that opens a new browser window that takes you out of Airtable. You could keep both the attachment and the url, but they might get out of sync and you really need to know the actual image on the CDN.

In this video I demo using my app Low Tech PDF with a premium license (a one time-flat fee per base) to preview an image url for the active record.

Here is the template that I used.

<h1>{{Name}}</h1>

<img src="{{Image URL}}" width="100%" />

Nice workaround.

Not so viable for big apps, especially for people constrained by the 10 apps limit ( :roll_eyes: ), but it might be a nice trick for a few people who need simple things like that. :thumbs_up:

Nice workaround.

Not so viable for big apps, especially for people constrained by the 10 apps limit ( :roll_eyes: ), but it might be a nice trick for a few people who need simple things like that. :thumbs_up:


If anyone has a new Pro workspace with the 10 app limit, I recommend reaching out to a consultant who can help them convert to a legacy pro workspace with unlimited apps.

Hello all.

Thank you for informing us at this time. We still have time. Therefore, we still have time to also make a change on the request, I believe.

Why don’t we give the user an option to make the column public or private based on a toggle on the creation of the field or editing the field? I believe that would make everyone happy.

With our implementation of https://nocodb.com/ , we enabled this feature, for example. We still use Airtable though. This will effect our public APIs, therefore we will have to find a solution to this. This will cause us to completely leave Airtable in the end, I believe.

@Al_Biedrzycki Would this possible to have this feature? Or, do we already have it? Thank you.

Thank you.

As I’m very new to Airtable, I’m not familiar with much of anything nuance wise here. So, was hoping someone with some more experience could translate: I am populating an Airtable table via my stores PoS API. The POS hosts the images for our products and I just pull the URL for the image in as a field to use on our website. Is this the kind of scenario that is impacted here? Perplexed newbie.

Terms & ConditionsAccessibility statement