Help

Re: URL to Attachment

5511 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Aaron_Phoenix
5 - Automation Enthusiast
5 - Automation Enthusiast

I have registration forms that collect a digital signature. It imports into airtable as a url, like this: (https://s3.amazonaws.com/files.formstack.com/uploads/3669579/85172110/582992994/signature_85172110.p...)

Can someone help me with a script that would convert this to an image attachment?

48 Replies 48

@Marty_McCoy It looks like the URL you’re trying to attach points to a web page, rather than a direct URL for the raw image. This means when you’re updating the record, you’re uploading HTML rather than the PNG/JPG/etc itself.

Have you considered using the URL preview app instead? This will allow you to preview Google Drive share URLs by clicking cells in grid view:

Previewing a Google Drive image from the URL preview app

Thanks @Stephen_Suen, I need to get them out of Google Drive because of limited storage. Does URL Preview work with Box? I have unlimited storage there.

Alternatively, do you know a way for me to access the URL for the raw image in Google Drive? It’d be great to use this URL to Attachment scripting solution for scalability.

Update

I got the script to import by using a link as follows: https://drive.google.com/uc?export=view&id=file_id

Update 2

After further testing, the script is not working consistently, even though all of the Google Drive links now point to the raw image, not the HTML. It works for a couple of records, then stops.

@Stephen_Suen any ideas to troubleshoot are appreciated.

Possibly helpful intel:

  • When I use Python’s requests library to download files from Google Drive, I use a base downloading URL https://docs.google.com/uc?export=download
  • Then, I pass in the the file ID and the destination where I want to save the file.

Maybe something similar needs to happen in this script? Use this base URL and the file ID, rather than using the other format (https://drive.google.com/uc?export=view&id=file_id).

Anybody else have a solve for this?

This sounds precisely like the known bug documented here and here.

I see this failure often across many clients despite many attempts hone the URLs into Google Drive using different patterns such as:

  • https://drive.google.com/uc?export=download&id=" + thisID
  • https://drive.google.com/uc?export=view&id=" + thisD

@Bill.French I tried using this URL pattern and it’s working right now. I am now not confident that it’ll work consistently, but glad it’s working at least sometimes. Thank you!

Marty_McCoy
6 - Interface Innovator
6 - Interface Innovator

Can’t edit my comment above. Last week, I used this script to process 322 google drive photo links in one click! But today it’s not working.

The URL Preview app doesn’t currently work with Box, but that’s a fantastic feature request! Many of my clients use Box, and I’m sure that this would be a very handy feature for them! Please submit this as a feature request to either the #show-and-tell:product-suggestions category, or by emailing support@airtable.com.

Last week, I used this script to process 322 google drive photo links in one click! But today it’s not working.

I actually don’t have the answer to solving this script problem for you, but I’ve setup my clients with Integromat in order to convert their Google Drive files into Airtable attachments.

Thanks Scott!

The script just worked for me to process 105 photos. Thankfully, I am in a position where if the script doesn’t work, I can wait an hour or two and try again and it seems there’s a good chance it’ll work then.

Marty, that does sound more like a rate limit (number of photos processed per x amount of time) than an issue with your script – so that’s good news!

Google Drive and Dropbox are tricky. They intentionally don’t make it easy to discover their URL patterns to “hotlink” an image using their server. Their services are meant for personal file sharing, not web hosting, which would cost them more bandwidth to provide their services. I deal with this limitation a lot.

I also believed this might be the suspected cause of such failures, but I was wrong.

The Test Climates

With more than three clients I have engaged in extreme measures to isolate issues concerning attachment inconsistencies and failures to process images as well as PDF documents. All of my tests and debugging activities are specific to the use of the Airtable API and Google Apps Script to perform mass extractions and attachment uploads into Airtable.

In 100% of the cases, we ultimately proved that document sources were not the cause. If the sources are properly configured for accessibility and the file URLs are constructed in a manner to reveal the actual artifacts (as opposed to rendering veneers), the Drive platform provided the climate for a successful extraction.

Rate Limiting

We also ruled out rate limiting and other quota breaches by performing mass high-velocity extractions into other systems such as local drives, network drives, and even Amazon S3 object stores. One test included the processing of 10,000 PDF documents from Google Drive into S3 over a five hour period without a single issue; roughly one TB of content.

It’s Airtable

As such, the failures that these three clients experience (even today) with their Airtable solutions are almost certainly in Airtable itself, not the document source platforms. To be clear, this causal assertion is with the Airtable as it pertains to the API only. There may or may not be other attachment issues with manual uploads or with other script processes in Blocks or automations but I can only speak to my experiences with the API.

The Pattern

If we’re talking about the same problem y’all are discussing here, the error condition is unmistakable - an API call into Airtable creates an attachment and for a few seconds it looks like the upload sticks because the UI indicates a document has arrived in the cell. The icon of the document is greyed out during this brief indication period which typically lasts a few seconds. Then the icon vanishes as if to suggest that Airtable tried to store the file but gave up.

Oddly, this behaviour is roughly the identical experience if you use the API to make an attachment using a URL that cannot be accessed by Airtable, a condition that should fail.

The Frequency of the Pattern

These observed failures are intermittent and from time-to-time there are periods where all attachment attempts via the API fail. And there are periods where all attachment attempts succeed. Largely, though, it seems they fail intermittently and randomly.

We also invested heavily in script processes that perform up to ten retries and capture upload success analytics when attachment attempts fail. The analytics from attachment attempts that are retired show equally random outcomes - sometimes a second retry succeeds; sometimes ten retries fail. And in almost every failure situation, a manual upload works.

I believe this issue is still creating problems from time-to-time and in very random cases and it has forced many of my clients to skirt the issue by avoiding attachments and referencing documents by URL only.