ExaVault API Troubleshooting

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 directed clients to 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 file content sent as the entire request body without requiring the Content-Type: application/octet-stream header.

If API uploads fail after migration with a 400 status error, check the Content-Type header. When the file upload is 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 representing either the resource's path or its 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 it received into this ID format. Files.com does not perform that automatic conversion and instead treats any string that does not begin with id: as a full path rather than a resource ID.

A call like GET /resources/download?resources[]=1234 is interpreted as a request to download the resource named 1234.

Resource IDs Were Not Preserved During Upgrade

Resource IDs hard-coded into code that uses the legacy ExaVault API are not valid on Files.com. Resources on Files.com have new and different IDs than they had on ExaVault.

In the best case, the code fails with errors that the requested resource cannot be found. In the worst case, the code behaves unexpectedly as it locates an unrelated item in the site.