Attachment Upload via Make (Integromat)

26 Jan 26 edit: Option 2 below appears to allow PDF previews fine but more confirmation would be helpful!


---
Hm that’s weird.  Could you provide some screenshots of your current setup?  

Two possible ways of uploading are:

1. Upload each attachment into Google Drive, make that uploaded file’s link public, and then use that public link in an Update Record / Create Record step
2. Upload the attachment directly into Airtable via a HTTP module 

I favour option 2 as it’s less setup / module uses.  For less technical users I’d recommend option 1 though

Edited to add: I just created a guide for option 2!

If this is urgent you may want to consider just making a Zap for this instead.  The last time I did this with Zapier they automatically created a temporary URL for the Gmail attachment that I could immediately use 

Hello!

I think we’re having the exact same issue! I’ve found that it is related to any attachment uploaded via the API. I have some that are done in n8n and some that are pure HTTP requests. As of Friday, 1/23/2026 any attachments made via the API will not open in the AirTable preview and instead trigger a download.  In my case they are downloading with a filename that is not the actual name of the file, and derived from the temporary URL used to upload them. However, the filename displayed in the Airtable base UI and record history is correct and if you expand the record or attachment field and click the small download icon next to the attachment, the file downloads normally and is named correctly. This only became an issue for us on Friday also. Any files uploaded via the API before that still behave as expected.

I’ve opened a support ticket to AT about this but have not heard back yet. Here is a excerpt of what I’ve shared with them:
 

When we attach a PDF via the API using an attachment object containing both a url and a filename, Airtable stores the attachment correctly and displays the correct filename in the UI. However:

• Clicking the attachment to preview it fails to load in Airtable’s viewer

• Instead, Airtable downloads the file automatically

• The downloaded file is incorrectly named get-temp-file (derived from the url in the API call instead of the provided filename)

• If we click the small download icon under the attachment in the expanded record view, it downloads with the correct filename

• The correct filename is also displayed in the UI

Example API Payload (sanitized)

{

  "records": [

    {

      "id": "recXXXXXXXXXXXX",

      "fields": {

        "PROOF": [

          {

            "url": "https://myserver/get-temp-file?file=recPbpn90ndbMw6NZ_0NSQ.pdf",

            "filename": "2026_Ninja_BusinessStrategy_Packet.pdf"

          }

        ],

      }

    }

  ]

}

Expected Behavior

• Clicking the PDF attachment should open it in the Airtable preview viewer

Actual Behavior

• Clicking the attachment attempts to preview, but the viewer fails to load the pdf

• The file downloads automatically and is incorrectly named:
  get-temp-file

• Clicking the attachment’s download icon downloads correctly using:
  2026_Ninja_BusinessStrategy_Packet.pdf

Additional Notes

• This began today

• API-created attachments from prior days are not showing this problem

Hm, I just ran some additional tests on this and reproduced the following:

1. PDFs uploaded via the Upload Attachment endpoint can be previewed fine on both Chrome and Firefox
   1. https://airtable.com/developers/web/api/upload-attachment
2. PDFs uploaded via the Create Record, Update Record or Update Multiple Record endpoints cannot be previewed on Chrome and instead automatically download it
   1. https://airtable.com/developers/web/api/create-records
      https://airtable.com/developers/web/api/update-record
      https://airtable.com/developers/web/api/update-multiple-records
   2. On Firefox, it shows a “Corrupted Content Error” and doesn’t automatically download it
3. PDFs uploaded via Make’s ‘Update a Record’ module exhibit the same behaviour as point 2
4. SVGs uploaded via the Create Record, Update Record or Update Multiple Record endpoints can be previewed fine

This seems...weird.  Seems like a PDF specific thing maybe?

---

​@RyanH_7G Hm, could I just check whether your n8n uploads worked?  Given that those should be happening through the API I’m assuming they didn’t work either?

Thanks for opening the ticket!  I’m very curious what they might say

​@TheTimeSavingCo You are correct, n8n uploads are exhibiting the same problem. Anxiously awaiting a response from support. I cc’ed our account rep too,  though I know if that will do anything.

Yup. Something is broken. PDFs are not showing up in the viewer. Thumbnails are fine and downloading works too. Tested on Edge & Safari.

Hi, same issue here :

• PDF file preview doesnt work, file gets downloaded instead
• PNG/JPG/HEIC preview works

This happens since Friday, looks like an Airtable bug.
 

Reporting the same issue. Workflows in n8n and Make trying to download the recently API-added (Update record endpoint) PDFs can’t download them. Can’t preview in Firefox (error message says it’s corrupt), in Chrome, the files are downloaded directly.

It’s breaking my client’s order production workflow, so it’s quite annoying. Don’t want to switch all the logic of the Upload Attachment endpoint

Please keep us posted

I have received an update from AirTable that their engineers are looking into this… we will see

We're experiencing the same issue and can confirm it's affecting downstream services as well.
 

Spotted issues:

1. Airtable Preview: PDFs won't preview, trigger instant download instead
2. CloudConvert Failures: Getting INVALID_CONVERSION_TYPE errors when trying to merge these PDFs
3. File Metadata Corruption: Filenames showing malformed encoding like UTF-8''filename.pdf, with trailing commas

Example of corrupted filename structure from our Make.com logs:

"filename": "UTF-8''cv-427f2f50-d567-4db7-89a8-2238d1eb4654.pdf, "
"filename": "UTF-8''education_certificate-dd76fd2a-fed5-41ca-b999-f0dd6b6b85ed.pdf, "

Compare to files uploaded before (working perfectly):

"filename": "LebenslaufXYZ.pdf"

Seems to me the PDF files are being stored with corrupted metadata that breaks compatibility with external services. Any workflow that retrieves these PDFs from Airtable for further processing is failing.

Hoping for a quick fix from the Airtable team! I reached out and they said “Our engineering team has been informed of the behavior and is looking into the issue now.”

Hope above information might help.

Same here, the problem is not with the API. It’s with ‘Add files from a URL’ in general

Same here. Fingers crossed this is a quick fix.

I’m seeing the same issue in my base affecting new file uploads from third-party form providers (Jotform, Fillout): images (JPGs, PNGs, etc.) are only impacted on iOS and macOS, while PDFs are impacted on iOS, macOS, and Windows. Android is not affected. This seems to have started over the weekend (1/24/26).

I have received word that this is resolved— it is indeed fixed on my end

Can confirm that it is fixed for us for new uploads only. Any PDFs that had the malformed metadata have not been fixed and we’re having to manually replace those or re-run automation flows to get them working:

Our engineers do recommend reuploading the attachments that were added to your base between Friday (Jan. 23rd) and today (Jan. 26th). Unfortunately, our engineers are unable to fix the metadata of these existing uploads to prevent the unwanted behavior from occurring when previewing them. Reuploading the PDFs/attachments to your field will help prevent the issue from happening with these existing files as well.

Yup. Working again. Reuploading though… That means having to regenerate a ton of PDFs as it’s part of a workflow. No chance.