The legacy ExaVault API accepted some requests which did not conform to the published standards.

After migration, some requests that previously worked may be rejected as invalid.

Error for Failed Uploads

The documentation for legacy API v2.0 POST /upload indicated that you should send a multipart/form-data formatted request body, attaching the file contents in binary form as the file field.

The legacy platform also accepted requests with the bytes of the content of the file sent as the entire request body without requiring the Content-Type: application/octet-stream header.

If API uploads are failing after migration, and you are receiving a 400 status error, check to see if you are sending the correct Content-Type header. If the file upload is being sent as a stream rather than a form attachment, send a Content-Type: application/octet-stream header.

Error Attempting to Download a File by ID

The legacy ExaVault API v2.0 accepts resource identifiers, which were a string that represents the resource's path or it's ID. When specifying a resource identifier that used the ID, the string must begin with the prefix id: followed by the identifier.

The legacy platform automatically converted any entirely-numeric value that it received into this ID format. Files.com will not perform that automatic conversion and will instead treat any string it receives that does not begin with id: as a full path rather than a resource ID.

This means a call like GET /resources/download?resources[]=1234 will be interpreted as a request to download the resource named 1234.

Resource IDs Were Not Preserved During Upgrade

If you have hard-coded any resource IDs into code which uses the legacy ExaVault API, that ID will not be valid on Files.com. Resources on Files.com have new and different IDs than they had on ExaVault.

If you are fortunate, your code will fail with errors that the requested resource cannot be found; if you are not fortunate, your code will behave unexpectedly as it locates an unrelated item in your site.