Skip to main content

I’m running into a confusing problem involving PDF attachments and third-party apps (specifically Noloco) that are connected to my Airtable base. Here’s a detailed explanation:

Background & Problem

  • I am using n8n (automation platform) to upload multiple PDF attachments to a field in Airtable.

  • In Airtable itself, everything appears correct:

    • The PDF filenames are always displayed exactly as expected (both in the UI and in the API attachment objects).

  • Noloco (an app builder which connects directly to Airtable) is showing incorrect or strange filenames for some attachments:

    • Instead of the real filename (e.g. 2025-08-06-21-43.PDF), Noloco sometimes displays a generic value like uc as the filename.

    • However, for attachments uploaded manually to Airtable (via UI), Noloco displays the correct filename.

What I Have Tried

  • I have checked the attachment objects both in the Airtable API and via scripting:

    • The filename property is always correct and matches what’s shown in the Airtable UI.

  • I built an Airtable automation using the scripting app to verify filenames and log them;

    • The filenames are always correct and there is no sign of the generic/incorrect names visible anywhere in Airtable.

  • I have hundreds of PDF files, so manually re-uploading them is not an option.

  • I understand that you cannot directly update an attachment’s filename in Airtable (only by deleting and re-uploading the attachment with the correct filename).

My Questions

  1. Where does Airtable actually store the filename property for an attachment?
    Is there any hidden layer or version that could be different from what’s shown in the UI and scripting?

  2. Is it possible (via scripting, automation, or API) to force an update or correction to the filename for an attachment—without re-uploading the file?

  3. Why would a third-party tool like Noloco see a different filename than what’s visible in Airtable?
    Is there any known caching, delay, or “internal” filename property that’s not visible to Airtable users?

  4. Has anyone experienced a similar issue with attachments uploaded by n8n (or Make/Zapier), where filenames mismatch only in downstream tools, but look fine in Airtable?

Further Details

  • All attachments are PDFs, stored in a multipleAttachment field.

  • The field and filenames are correct for every record as seen in Airtable and via API.

  • Problem occurs only for some records, and only in Noloco; there’s no pattern I can see.

  • Re-uploading a PDF via Airtable UI “fixes” the issue in Noloco, but that’s not practical for us.

If there’s any way (official or workaround) to ensure the “real” filename is always what is shown and passed to third-party tools, I would appreciate any advice!

Thank you for your help and insights!

Hopefully someone else can answer your questions, but I was curious whether using an automation to reupload everything worked for you?

I downloaded and re-uploaded it in the same way as the original upload. That's why I got the same result. As long as I don't know how to prevent this, I can't solve it.

This doesn’t sound like an Airtable problem. It sounds like a Noloco problem. I would open a support ticket with Noloco about this.

Also, if the problem only occurs with attachments that are uploaded via Noloco, then it’s definitely a Noloco issue because the filename is specified during the API call.

- ScottWorld, Expert Airtable Consultant

Hey ​@jhms,

If you do conclude that this is a Noloco issue, then you might want to check out/post on their community or talk to the support chart that will pop-up there.

On the other hand (I don’t think that will be the case) you believe this is an Airtable issue, then feel free to reach out to support@airtable.com.

If you expand the record details of your record, and check the revision history, you should be able to see what name the file had (I believe) at the time of creation -which will also make reference to the fact that it was created via API.

Mike, Consultant @ Automatic Nation

Hi ​@jhms,

 

could it be that the few impacted attachments contain special characters in their name?
NoLoco uses Airtable’s Webhook API which treats file uploads uploaded through the UI exactly like attachments uploaded through the api, I cannot see how that has an impact.
Agreeing with the crowd here that this seems to be a NoLoco issue. If you found the solution let us know what it was! :D

Best,
Richard

This doesn’t sound like an Airtable problem. It sounds like a Noloco problem. I would open a support ticket with Noloco about this.

Also, if the problem only occurs with attachments that are uploaded via Noloco, then it’s definitely a Noloco issue because the filename is specified during the API call.

- ScottWorld, Expert Airtable Consultant

Thank you. For me, it's a problem with the interaction: Noloco uses strange data fields, and Airtbale won't let me edit them.

I've created a request with Noloco. I haven't received a reply yet.


 

Hey ​@jhms,

If you do conclude that this is a Noloco issue, then you might want to check out/post on their community or talk to the support chart that will pop-up there.

If you expand the record details of your record, and check the revision history, you should be able to see what name the file had (I believe) at the time of creation -which will also make reference to the fact that it was created via API.

Mike, Consultant @ Automatic Nation

Thank you.
The files were uploaded by n8n. They were imported via a share link from Google Drive.

The files were then copied to a different Table using automation in Aritable. 

The file name is always displayed correctly in Airtable. I don't see any changes in the file names in the history.
 

Hi ​@jhms,

 

could it be that the few impacted attachments contain special characters in their name?
NoLoco uses Airtable’s Webhook API which treats file uploads uploaded through the UI exactly like attachments uploaded through the api, I cannot see how that has an impact.
Agreeing with the crowd here that this seems to be a NoLoco issue. If you found the solution let us know what it was! :D

Best,
Richard

There are European characters in the file names, but nothing to exotic.
When I solve it, I'll give an update.


When I examine the packets using the browser's inspector tool, I found this:

 

Terms & Conditions