Help

Re: API: Uploaded attachment types are wrong

Solved
Jump to Solution
3911 1
cancel
Showing results for 
Search instead for 
Did you mean: 
Jed_Davidow
6 - Interface Innovator
6 - Interface Innovator

I have successfully gotten airtable to upload a PNG and a PDF from Dropbox.

But when airtable processes the file, the type is listed as text/html

If I include a type field, I get an error:

{
	"fields": {
		"Type": "Test",
		"Comment": "",
		"Attachments": [
			{
				"url": "https://www.dropbox.com/s/XXXXXXX/robots.png?dl=1",
				"type": "image/png"
			}
		],
		"User": "",
		"Part": [
			"recFI6JhdkwTCeB9q"
		]
	}
}

And I receive this:

{
	"error": {
		"type": "INVALID_ATTACHMENT_OBJECT",
		"message": "Invalid attachment object for field Attachments: {\n  \"url\": \"https://www.dropbox.com/s/XXXXXXXX/robots.png?dl=1\",\n  \"type\": \"image/png\"\n}"
	}
}

But if i just strio out the “type” there is no error, just the type is wrong.

1 Solution

Accepted Solutions

You’re welcome! Glad I could help! :slightly_smiling_face:

To address your other question:

No, the ?dl=1 parameter doesn’t break the file upload to Airtable. You could remove that parameter altogether and your upload to Airtable still wouldn’t work.

The reason it isn’t working is because you’re using Dropbox’s share link that starts with https://www.dropbox.com

That share link doesn’t actually give you the link to the file itself. It is giving you a link to a Dropbox webpage that has the file embedded in it. If you go to your link in a web browser, you will see that you are not taken to the file itself.

In order to extract the actual file from that webpage, you would need to change the beginning of your share link to https://dl.dropbox.com

That will extract the file itself, and you can also see the difference if you go to that URL in your web browser.

See Solution in Thread

20 Replies 20

Attachments accept a URL parameter and an optional filename parameter. There is no type parameter.

You can find this information in the Airtable REST API documentation.

Cresting a new attachment involves only a url and an optional file name. However, the read value of an attachment field does include a file type.

It could be that Airtable is having a hard time determining the file type from the url because your url has query parameters and does not end in a file name. If you include the file name in the value you send to Airtable, Airtable may have more success in determining the file type.

Ah, Thank you. I was using the custom api page for my base to get started,bdidnt think to check the actual documentation to see if the parameter was valid as an input.

Ah! Got it, the dl=1 param breaks the parse for the file extension. I’ll try out the filename param later.

Is there a way to update the type manually? Right now it’s just pdfs and pngs, but we will probably upload binaries and various txt formats.

You’re welcome! Glad I could help! :slightly_smiling_face:

To address your other question:

No, the ?dl=1 parameter doesn’t break the file upload to Airtable. You could remove that parameter altogether and your upload to Airtable still wouldn’t work.

The reason it isn’t working is because you’re using Dropbox’s share link that starts with https://www.dropbox.com

That share link doesn’t actually give you the link to the file itself. It is giving you a link to a Dropbox webpage that has the file embedded in it. If you go to your link in a web browser, you will see that you are not taken to the file itself.

In order to extract the actual file from that webpage, you would need to change the beginning of your share link to https://dl.dropbox.com

That will extract the file itself, and you can also see the difference if you go to that URL in your web browser.

That was it! using “filename”:“robots.png” did not work (came up as application/binary).

Now, I need to figure out from the dropbox API how to get that link and not the www link.

I don’t know if the Dropbox API gives the ability to retrieve that link, so you might need to work out some other methodology of changing the URL to the proper download URL.

You could easily do this with a formula field in Airtable (use the “substitute” function to replace “www” with “dl”).

You could also easily do this with a Javascript.

On my end, I don’t actually know Javascript, so I handle these sorts of automations using Make.com, where they give you the code for how to do this substitution at the very bottom of this page. (It’s not letting me give you the link to the exact part of the page, so just scroll all the way to the bottom.)

In other words, I have Make.com handle the entire process for me — I have Make grab the file from Dropbox, change the URL to the proper download URL, and then upload that file to Airtable.

It does.

String url = meta.getUrl();

That is their Java library? I am not using java. I have to implement from HTTP calls.

Regardless, the link that the Dropbox API provides is not the dl.dropbox.com link, but the www.dropbox.com/XX?dl=0 link; at least, that’s what I get when I use the sharing//create_shared_link_with_settings endpoint. I looked through the settings, I don’t see anything that updates the URL to dl.dropbox.

I also tried files/get_temporary_link

This may be splitting hairs, but since I am retrieving the link from Dropbox, I would prefer to not have to modify it to use with airtable and worry that the domain will change in the future (though how much of the web would that break?)

I doubt that the dl.dropbox.com prefix would change since it’s been that way for so long, but who knows?

Dropbox doesn’t seem to provide the dl link through HTTP calls, which is why I use Make for this.

However, this is also a good reason to switch to Google Drive, which does provide the actual file link in its HTTP calls.

Unfortunately, my company doesn’t officially support GDrive, so I am stuck with DB for now.

Oh, I’ll check out Make.

However, that’s adding one more tool to the chain. Using this API is sort of tangential to our group’s work, and it needs to be as robust and solid going forward as possible, as this type of thing is not typically within my group’s purview (hardware testing group, mostly EEs and not coders). It looks cool, but if it’s not stable enough to last indefinitely, I will shy away. Airtable was a hard enough sell to the upper management.

@Jed_Davidow

I think that with the combination of Make and Airtable, you guys should be on solid footing for years & years into the future.

Not sure how large your company’s budget is, but if you have a budget to hire an expert Airtable/Make consultant to help you with any or all of this, please feel free to contact me through my website:

Airtable consulting — ScottWorld

No, it’s their rest API and this reference is javascript, not java.

I was answering this question.

The DropBox [REST] API supports this; that’s all I was saying.

I’m pretty sure this:
https://www.dropbox.com ... ?dl=1

… is the same as this:
https://dl.dropbox.com ...

That’s because you are expecting create_shared_link to be an API endpoint and it is not. It is simply a document viewer address (as @ScottWorld said) which cannot be used by Airtable to create attachments.

Indeed it is. One more cost. One more complexity. One more wrinkle capable of failure. But, @ScottWorld was not given any wiggle room - you said…

I have to implement from HTTP calls.

And by “calls” I assume you mean direct HTTP GET requests. Either you need to use the DropBox API (which you ruled out), or you need to use something that performs the DropBox API calls for you. Make does the latter. You also ruled out Google Drive which handles all of these little rendering nuances for you.

And speaking of DropBox, wasn’t there an Airtable plugin that integrated documents automatically?

I only see other 3rd party integrations.

I am gonna have to look at AWS or GDrive. I just read into Dropbox and their tokens expire after 4 hours requiring a refresh token, and that’s no good for deploying to a couple dozen unmanned systems.

Airtable has similar signed URLs coming to attachment files November 8th I believe.

Sorry to drag up and old thread, but I have using the same process (Dropbox to Airtable via make) for quite some time and it has been stable, however over the last two days I have noticed the old disappearing attachment issue in Airtable again. Has something changed with the Dropbox link? Currently I am using make to edit the link to have the dl at the beginning of the URL. It may be a temporary issue, but wondering if anyone else has experienced something similar?

Just to provide a little more information, I have looked back at my Make.com logs (30th May) and I can see that the Dropbox module was outputting a different URL. I haven't changed anything in the Dropbox module so I wonder if they updated something on their end?

The original output URL was: https://www.dropbox.com/s/XXXXXX/FileName.pdf?dl=1

And has now changed to: https://www.dropbox.com/scl/fi/XXXXXX/FileName.pdf?dl=1&rlkey=XXXXX

@ScottWorld any idea on why this has changed? and if there is a workaround? As I said, I have no idea if this is what has caused the vanishing files again, but it does seem to be rather suspicious if not.