API: Uploaded attachment types are wrong

[Jed_Davidow]

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.

[Jed_Davidow]

Bill.French:

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?)

[ScottWorld]

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.

[Jed_Davidow]

ScottWorld:

However, this is also a good reason to switch to Google Drive

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

[Jed_Davidow]

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.

[ScottWorld]

@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

ScottWorld • Best Airtable Consultants, Airtable Experts, Airtable Consulting,...

ScottWorld • Best Airtable Consultants, Airtable Experts, Airtable...

ScottWorld provides the world's best Airtable consultants, expert Airtable training, best Airtable consulting, and Claris FileMaker Pro developers.

[Bill_French]

Jed_Davidow:

That is their Java library? I am not using java.

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

Jed_Davidow:

I have to implement from HTTP calls.

I was answering this question.

Jed_Davidow:

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

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

Jed_Davidow:

that’s what I get when I use the sharing//create_shared_link_with_settings endpoint.

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.

Jed_Davidow:

I’ll check out Make … However, that’s adding one more tool to the chain.

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?

[Jed_Davidow]

Bill.French:

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.

[Bill_French]

Jed_Davidow:

their tokens expire after 4 hours

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

[Theo_Field]

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?

[Theo_Field]

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.