# File de-duplication options not working

**URL:** <https://community.hubspot.com/t/file-de-duplication-options-not-working/79999>\
**Category:** APIs & Integrations\
**Tags:** free\
**Created:** [April 25, 2023, 1:20pm UTC](https://community.hubspot.com/t/file-de-duplication-options-not-working/79999 "2023-04-25T13:20:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![wollivier](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/wollivier/32/198408_2.png) [@wollivier](https://community.hubspot.com/u/wollivier)\
**Post date:** [April 25, 2023, 1:20pm UTC](https://community.hubspot.com/t/file-de-duplication-options-not-working/79999/1 "2023-04-25T13:20:30Z")

</div>

Hello,

It seems that in v3 of the Files API, the de-duplication options, although provided as per the documentation, are ignored, and a copy of the file is created every single time.

This happens whether I use the Python client, or CURL.  
For example, when I run the following command twice in a row, I get a different file ID, even though the file is the same, as well as all the other parameters. This seems to happen regardless of the folderPath, the access level of the file uploaded, a

curl -XPOST [https://api.hubapi.com/files/v3/files](https://api.hubapi.com/files/v3/files) --header ‘authorization: Bearer YOUR\_API\_TOKEN’ -F folderPath=/test -Foptions=‘{“access”: “PUBLIC\_NOT\_INDEXABLE”, “duplicateValidationScope”: “EXACT\_FOLDER”, “duplicateValidationStragegy”: “RETURN\_EXISTING”}’ -F file=@/tmp/example.txt

Also, the documentation does not say how de-duplication is performed. Is it using file names, MD5 or SHA1 hashes, or some other method?

---

<div class="post-metadata">

**Author:** ![Jaycee\_Lewis](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/jaycee_lewis/32/61352_2.png) [@Jaycee\_Lewis](https://community.hubspot.com/u/Jaycee_Lewis)\
**Post date:** [April 26, 2023, 4:12pm UTC](https://community.hubspot.com/t/file-de-duplication-options-not-working/79999/2 "2023-04-26T16:12:46Z")

</div>

Hey, @wollivier 👋 Thanks for flagging this. I’ll be glad to set up a test and reproduce on my end.

A few questions,

- have you tried using ENTIRE\_PORTAL vs EXACT\_FOLDER?
- have you tried using REJECT vs RETURN\_EXISTING?

I ask out of curiosity, not because you didn’t provide enough information.

Thanks for the additional details! — Jaycee

---

<div class="post-metadata">

**Author:** ![wollivier](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/wollivier/32/198408_2.png) [@wollivier](https://community.hubspot.com/u/wollivier)\
**Post date:** [April 26, 2023, 4:27pm UTC](https://community.hubspot.com/t/file-de-duplication-options-not-working/79999/3 "2023-04-26T16:27:49Z")

</div>

Hi [@Jaycee\_Lewis](https://community.hubspot.com/t5/user/viewprofilepage/user-id/127074) ,  
I’ve just given the various options a go, and found that whatever the combination of options was, the API would always create a new file, with incrementing IDs.  
There was one strange thing I observed, which might be on purpose, but not documented, so thought I’d mention it here:

- The first 4 copies of the file are renamed by adding a `-{1..4}` suffix to the basename of the file, like so:

- The following copies of the file are renamed by adding a textual timestamp to the basename of the file, like so:

So it genuinely seems that the feature is not working at all.  
Regards,  
Will