Upgrading From ExaVault

Logging In On The Web

Just as with ExaVault, there's three things you need to connect to Files.com via the web: the site address of your account, your username, and your password.

• Site Address: You can still use your old account address from ExaVault to connect on the web, or you can connect to Files.com directly. For example, if your old domain was example.exavault.com, connecting to either example.exavault.com or example.files.com will take you to your account. There are no plans to discontinue your old account address; the Files.com platform will support the exavault.com domains for the foreseeable future.
• Username: You will use the same username for your Files.com site that you used with your ExaVault account. Nothing changes.
• Password: Your password is not changed during the migration to Files.com. No changes are needed.

Uploading and Downloading On The Web

Once you are logged into the Files.com web interface, downloading is very similar to ExaVault's web file manager:

• Click on a file name to preview and download
• To download multiple items at once, tick the checkboxes to the left of each item and then click the Download button in the toolbar that appears at the top of the page.

If you can upload within your current folder, you can click the Upload files button a the top of the page to upload any file from your computer. If your web browser supports it, you'll also see a button for Upload folder that allows you to select an entire folder (or folder tree) to upload at once.

File Paths Are Not Case-Sensitive

Files.com is designed for case-insensitive storage of file and folder paths for compatibility with many enterprise software storage integrations. This means that filenames that differ only by uppercase versus lowercase are treated as identical by the platform.

User Permission Types Are Different

ExaVault's user permissions mostly correspond with the permissions that can be assigned to users in the Files.com platform, with some notable changes.

• There is an Admin permission on the Files.com platform which provides admin-level access (such as changing folder settings) without providing site-wide administrator access.
• Lower-level permissions, such as the ability to list the contents of a folder, are automatically granted if a user has higher-level permission, such as the ability to download from a file or folder.

The table below summarizes the equivalent permissions from each platform.

Users Can Have Complex Permissions

ExaVault user management supported one set of permissions for all the files and folders a user could access. The Files.com platform is more robust, allowing for varied permissions applied across separate, unrelated folders for a single user.

User Home Folders Are Not The Root (mostly)

On ExaVault, a home folder for a user was always represented to that user as the entire contents of the account. Within Files.com, there is a setting to mimic this behavior for FTP connections, but not for the web interface. This means that users will be able to see the full path to any items they can access, even though they will not be able to interact with any files or folders that they do not have permissions to.

Many System Settings Can Be Configured Per-Folder

On the ExaVault platform, most settings take effect at the account level, except for sharing, notifications and direct links. The Files.com platform makes many more settings available on each folder. Site admins and users with admin access to a folder can:

• Automatically rename files uploaded to a specific folder.
• Limit which types of files can be uploaded to a folder.
• Automatically delete files in a folder after a certain number of days.
• Change the logo that is displayed when a user accesses a folder.
• Automatically encrypt or decrypt files uploaded to a folder.
• Manage other users' email notifications for activity in a folder.

System Emails Are Sent From no-reply@files.com

You may need to update rules for spam filters to ensure you can receive important messages, such as

• Password Resets
• Notifications of Failed Automations
• Share Link Invitation Emails
• Site Administration Emails

On ExaVault, system messages came from email@exavault.com. Once your site is migrated to the new platform, those system emails will be sent from no-reply@files.com, and the Reply-To address will be the email address that was originally used to sign up for ExaVault.

The Pricing Model

ExaVault operated under different pricing than Files.com. On ExaVault, accounts were not billed for individual users, nor for exceeding storage space. This also meant that it wasn't always economical to add all of your users to the system, depending on the plan. The Files.com platform does include billable users and storage overage charges. Along with all of its other features, Files.com provides the tools to help you monitor and manage your costs, such as the Account Usage dashboard.

Upgrading to the Files.com platform does not automatically change your billing. Files.com sales staff will reach out a few months after your migration to review your contract.

Full-Service Account Management

To manage your ExaVault account - such as changing your account billing or plan, it was necessary to maintain a separate set of credentials for the Client Portal. Files.com provides a single web interface for interacting with your site, including designating specific users as Billing administrators, who can view and update information regarding your account, payments, and invoices.

Files.com Is A Global Platform

ExaVault had data centers only within the US, and only provided an English-language interface. Files.com maintains service and storage instances in AWS across the globe with a fully internationalized interface available in 6 languages.

There are several other key improvements the Files.com global platform offers:

• Administrators can restrict some or all of the account storage to a specific region (USA, Australia, Canada, UK, EU, Japan, or Singapore).
• By default, Files.com will automatically route users to the fastest transfers based on their physical location.
• Individual users can choose a different preferred language setting from your site's preferred language.

API-First Development

ExaVault's API documentation and SDK often lagged behind the development of new features. Files.com takes an API-first approach to all development. This has several key benefits:

• API documentation and SDKs are auto-generated at the same time that new features are released.
• SDKs are always up-to-date with the current functionality available in the Files.com platform.
• The Files.com web interface, Desktop app, and FTP backend use the exact same API that we publish to our customers, so everything you can do in the UI can also be accomplished using the API or with one of our SDKs.

Command Line Interface (CLI) App

One of the unique benefits of Files.com's SDKs is our Command Line Interface, or CLI, application. The CLI is a turnkey, cross-platform API client for interacting with the Files.com API without needing to develop a full application. The CLI provides unlimited potential for extending the Files.com platform to support your business flows with as little investment as possible.

The File Manager

When you first log into your account, the web application will automatically take you to the files section. Just like with ExaVault, this is where you will do anything relating to the files and folders within your account. The Files option in the left-hand navigation will take you back to the file manager.

The Files.com File Manager does not display the sizes of folders' contents in the file listing. This is a change from ExaVault, where an entry representing a folder also included the total size of all its contents. If a folder's contents are stored within the Files.com platform, the entry in the Size column will include a button to calculate the current size of the folder. If a folder is a remote server mount, no button to calculate the size is displayed because no Files.com storage is being used for the folder.

Learn more about the using the Files.com File Manager

User Management

In ExaVault, the Users page was its own section of the left-hand navigation. Now, you'll find it in the settings of the web application. To get there, click on Settings > Users.

Read more about creating and managing your users

Shared Folders

Just like with ExaVault, you have the ability to create special links so that external users can access some of your files without needing their own credentials. ExaVault's Shared Folder feature is replaced on Files.com with the Share Links feature.

You can create new share links from within the files area by checking the items to be shared and then clicking the New Share button at the top of the files listing.

You can view your existing share links by clicking on the Sharing option in the left-hand navigation.

Share Links offer powerful functionality compared to Shared Folders:

• Share multiple folders at once
• Share the same folder in multiple share links with different levels of access.
• Customize the URL for a share link
• Limit the number of times a share link visitor can use their link
• Add a custom registration form to collect information from share link visitors.
• Create Clickwraps - terms that users must agree to before they access your share link.

Receive Folders

ExaVault's Receive Folders allowed users to create a method for external contacts to submit files to your account without needing their own user credentials. The Receive Folder feature is replaced on Files.com with the Share Links feature - when you create your new share link, you'll set the "Allowed Actions" to permit uploads.

You can create new share links from within the files area by checking the folder to be shared and then clicking the New Share button at the top of the files listing.

You can view your existing share links by clicking on the Sharing option in the left-hand navigation.

Share Links offer powerful functionality compared to Receive Folders:

• Share multiple folders at once and allow share link recipients to choose which folder(s) they will upload to.
• Use the same folder in multiple share links.
• Customize the URL for a share link
• Limit the number of times a share link visitor can use their link
• Add a custom registration form to collect information from share link visitors, and re-use that same form for multiple share links.
• Create Clickwraps - terms that users must agree to before they access your share link.

Another feature which is very similar to Receive Folders is Files.com's Inboxes. Just like receive folders, inboxes allow you to collect registration information and provides a way for external parties to upload files to you without requiring a user login.

There are some key differences between Inboxes and Share Links that will determine which makes sense for you:

1. Inboxes can only be created by site administrators, while Share Links can be created by any user who has both "SHARE" and "WRITE" permissions to the folder they're using.
2. Inboxes are permanent and account-wide, while Share Links have an expiration.
3. Inbox links can be displayed on the login page of your account.
4. Inboxes can receive files attached to an email.

Send Files

ExaVault's Send Files functionality allowed you to send specific files and folders to your external contacts without requiring you to set up user credentials. On Files.com, you will use the Share Links feature to send files to those contacts.

You can create new share links from within the files area by checking the items to be shared and then clicking the New Share button at the top of the files listing.

You can view your existing share links by clicking on the Sharing option in the left-hand navigation.

Share Links offer powerful functionality compared to Shared Folders:

• Customize the URL for a share link
• Limit the number of times a share link visitor can use their link
• Add a custom registration form to collect information from share link visitors.
• Create Clickwraps - terms that users must agree to before they access your share link.

Send Files Internals

On the ExaVault legacy platform, sending files actually created a copy ("snapshot") of the items you sent, and that snapshot existed independent of the files in your account. This meant you could send a file and then delete it from your account, and your recipient would still be able to access their file. In addition, it is possible on the legacy platform to directly upload a file during the send process, and that file would not appear in the site.

On the Files.com platform, share links generate a link to the live version of the files and folders you're sharing. This means that if you create a share link for a file and then delete the file from the site, your share link recipient will not be able to access the file. Similarly, if you create a share link for a folder and then change the contents of that folder, the share link contents will reflect the changes you made.

Development is underway to support this legacy "snapshot" capability within the flagship platform Share Links feature, although a launch date is not yet available.

Notifications

Files.com's email Notifications are very similar to the notifications in ExaVault.

To create a new notification in the Files area, click the Folder Settings button. If you're a site administrator, you'll see a wide array of powerful features that you can set up for your folder, including Email Notifications. If you're not a site administrator, you'll only see a form to create your own notification for the folder.

To view a listing of all your notifications, click on your username at the top of the screen and choose My Account. You can update, remove or add new notifications from that page for any folder you have access to.

Files.com Notifications include some exciting improvements:

• Site admins can manage notifications for other users and even for user groups.
• Specify a pattern to match against filenames and limit a notification to a specific file type.
• Choose how often notifications are delivered.

Activity Logs

ExaVault account administrators have access to Session Logs, or Activity Logs. These are also made available in Files.com as History to site administrators or to users who have the "History" permission for a folder (for some plans).

To access the logs for a specific folder, click on the File History button that appears at the top of the file listing for your folder. If you are a site admin, you can also see history at Settings > Logs > History.

Just like ExaVault, the FIles.com History listing allows you to filter the history by a date range, the type of action, the user, the file and folder paths and IP address. You can also export the listing to a CSV file for importing into a different system.

Files.com retains file history for 7 years, a huge improvement from the 90 days of retention offered on ExaVault.

Direct Links

In your ExaVault account, administrators can assign a direct link to a folder, making it available for web downloads without tracking any share invitations. Now that your site is migrated to Files.com, you have access to Public Hosting.

With Public Hosting, also known as Publicly Serve or Web Hosting, site admins (or user with Admin rights to a folder) can assign a public URL to that folder and all of its contents.

Public Hosting offers several improvements over the ExaVault feature:

• You can customize the link to the folder, and prevent revealing the entire path within your account.
• You can create multiple distinct URLs to the same folder.
• You can enable HTTP basic authentication, assigning a username and password to the link.

Branding

Make changes to your site's branding, such as the logo or custom domain, at Settings > Site Identity.

In addition to the customizations you're used to, Files.com offers even more options as part of the Site Identity settings:

• Choose custom interface colors.
• Add your own custom icons as well as the site logo.
• Display a different logo in the web interface for various folders.
• Add a custom header or footer to the web interface.
• Add a message to your login page.

Webhooks

Webhook settings are migrated along with your account settings, so any webhook you have configured on your ExaVault account will be created for your Files.com site. As much as possible, the Files.com webhook request will be identical to what was sent from the ExaVault platform. The X-ExaVault-Signature header will be calculated in the same way after the migration.

Changes to Migrated Webhooks

• Webhook requests sent by the Files.com platform will include a User-Agent header of Files.com Webhook
• For v1-formatted webhooks, creating a folder will trigger a request with the action of "Upload" rather than "Create Folder"
• For v1-formatted webhooks, renaming an item will trigger a request with the action of "Move" rather than "Rename"
• For v2-formatted webhooks, creating a folder will trigger a request with the action of resources.upload instead of resources.createFolder.
• For v2-formatted webhooks, renaming an item will trigger a request with the action of resources.move rather than resources.rename.
• For v2-formatted webhooks, some of the date fields, such as accessedAt or createdBy are not supported for every operation, and will be null.
• For v2-formatted webhooks, the eventData.resources.hash will contain a placeholder value.

Managing Webhooks

Site admins and users with admin rights to a folder can configure Webhooks at Settings > Integrations > Notification Services. Users with admin rights to a folder can manage webhooks for a folder from the Folder Settings button within that folder.

The Webhooks feature of the Files.com platform offers some improvements over the previous platform:

• Assign a backup URL for the webhook listener, in case the primary listener is offline.
• Add custom headers to the webhook request sent by Files.com.
• Use custom patterns so that only certain types of files can trigger the webhook.

If you wish to use the Files.com body format rather than the legacy v1 or v2 formats offered from the ExaVault platform, other features are also available:

• Change the HTTP method of the webhook request sent by Files.com.
• Use XML encoding for the webhook request
• Attach the file which triggered the webhook to the request sent by Files.com

Site admins can view the results of webhook calls made from your Files.com site to other systems at Settings > Logs > Webhook logs. Webhook logs are retained by the system for 30 days.

Multi-Factor Authentication

The ExaVault Multi-Factor Authentication (MFA) feature is known as Two-factor Authentication (2FA) in the Files.com platform.

If your plan allows it, you can require all the users of your site, or just the site administrators, to use a two-factor login when they connect. The Files.com 2FA feature provides several key improvements over the other platform - site administrators can make up to 5 different 2FA methods available to users, and can exempt individual users from 2FA requirements.

Site administrators can find the 2FA settings for their site at Settings > Users > User Settings. Each user can locate their own 2FA settings by clicking on their username in the upper-right corner and locating the Two-factor authentication section.

IP Address Restrictions

Your IP Address Restrictions from ExaVault are automatically migrated to the IP Whitelist settings within your Files.com site. Site administrators can see the IP Whitelist settings at Settings > Users > User Settings.

IP Whitelists have some important changes from the previous platform:

• Individual users can be restricted to specific IP addresses.
• Individual users can be allowed to connect from any IP address, not just those listed as allowed for the site.
• Files.com also supports allowing or disallowing connections from specific countries (which is enforced by IP address).

Account Usage Dashboard

Files.com provides an Account Usage dashboard to track the amount of storage space, transfer, users and API calls that have been used by your site. This can be accessed by site administrators at Settings > Account.

Getting Support

ExaVault's self-service customer support model operated mostly via receiving email requests, which customer support staff would attempt to match up with an account owner. This could result in delays in receiving support. At Files.com, we take pride in providing you with quality support from the first point of contact, which is possible because only site administrators can submit a support ticket through the web interface. This allows us to look in detail at your site configuration, user history, and billing information.

You'll be able to specify the impact an issue has on your business (from Low to Critical) and provide customer service with the appropriate level of access to your account.

If a site administrator isn't able to submit a support ticket, you can also email the our Customer Support team at support@files.com or call (800) 286-8372 Monday through Friday from 9am to 8pm Eastern.

Trash Can

Some ExaVault customers had access to the Trash Can feature, and could restore recently-deleted items to their ExaVault account, but most ExaVault customers could not reliably restore deleted files. Files.com provides a configurable retention period for deleted files, and our support team has procedures that will allow them to restore deleted files which you may request via support ticket.

Summary Table

No patience? No problem! Use the table below to locate the help documentation for the feature you need.

Legacy API Code Will Connect in the Same Way

API URLs stay the same. After your account is migrated, the URLs used by API code will continue to function. If you accessed the API through the accountname.exavault.com address, that same address will still work. If you used api.exavault.com as the host name, that host will continue to work as long as you are using your migrated API keys.

If you create new API keys after your site has been migrated, you cannot use the api.exavault.com hostname for the legacy API.

API Keys are migrated. All of your existing API keys will be migrated along with the rest of your account data and can be used the same way they were before.

Permanent Access Tokens are migrated. Access tokens associated with a specific user, which were created through the ExaVault web file manager will be migrated along with the rest of your account data. Temporary access tokens will not be migrated, so you will need to retrieve a fresh token using the authenticateUser method.

Code using legacy SDKs should work. For all of the supported methods, the previously published SDKs should continue to work without modification. The contents of some responses may now contain placeholders or empty values, but SDKs should continue to function as expected without needing an update.

Using Files.com API Keys with the Legacy ExaVault APIs

After your migration is complete, you can create a new API key in our migrated Files.com site and supply that to the legacy ExaVault API. If you create new API keys on your migrated site, your API code cannot use https://api.exavault.com as the base URL.

The legacy ExaVault API supported two different methods of authentication - you could use the v1.2 GET|POST /authenticateUser to create a new access token for each session, providing the user's credentials; you could also use permanently-assigned access tokens (created via the legacy ExaVault web file manager). Tokens created in either method are compatible with both versions of the legacy ExaVault API.

To create new API Keys for your existing code after your site has migrated, you'll either create a site-wide API Key (if your code makes use of the v1.2 GET|POST /authenticateUser function) or a user-specific API Key (if your code relied on a permanent access token).

Using Files.com Site-Wide API Keys with Legacy API v1.2-style authentication (Session Access Tokens):

1. Create a new site-wide key in your Files.com account.

2. Supply that key in the api_key ( or api-key )header when making a request to /authenticateUser

3. In subsequent requests to the legacy v1.2 API, provide the returned access token for the access_token parameter and the site-wide key for the api_key ( or api-key )header. If you're using any legacy v2.0 endpoints, supply that key in both the ev-api-key and ev-access-token headers on all requests

Using Files.com User API Keys with Legacy API v2-style authentication (Permanent Access Tokens):

1. Create a new API Key for a specific user in your Files.com account.

2. Supply that key in both the ev-api-key and ev-access-token headers on all requests to the Legacy v2 API. For any requests to the Legacy v1.2 API, supply the user key in the api_key ( or api-key ) header and access_token parameter.

Troubleshooting Code That Uses the Legacy ExaVault API

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 API v2.0 accepts resource identifiers, which is 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. The translation layer 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 Changed During Migration

If you have hard-coded any resource IDs into code which uses the legacy ExaVault API, that ID will not be valid after your site is migrated to the upgraded platform. 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.

Legacy ExaVault API v 2.0

Supported Methods:

• POST /users (Create a user)
• GET /users (Get a list of users)
• GET /users/{id} (Get info for a user)
• DELETE /users/{id} (Delete a user)
• PATCH /users/{id} (Update a user)
• GET /resources/list (Get a list of all resources)
• GET /resources/{id} (Get resource metadata)
• PATCH /resources/{id} (Rename a resource)
• DELETE /resources/{id} (Delete a resource)
• DELETE /resources (Delete resources)
• POST /resources (Create a folder)
• GET /resources (Get resource properties)
• GET /resources/list/{id} (List contents of a folder)
• POST /resources/copy (Copy resources)
• POST /resources/move (Move resources)
• GET /resources/preview (Preview a file)
• POST /resources/upload (Upload a file)
• GET /resources/download (Download a file)
• GET /account (Get account settings)

Changes for version 2.0:

• The include parameter is not supported for operations that previously accepted it, and will be ignored. The included property of a response will always be an empty array.
• The relationships property of a response will contain placeholders and not actual IDs of related records.
• There is no master user on the Files platform, only admin and user.
• User permissions are approximations of the permissions available to users on Files.com, so some combinations of permissions are no longer supported e.g., it is not possible to create a user who has "upload" but not "list" permissions, so users with "upload" permissions will be automatically granted "list" permissions.
• If a user has "download" permissions, they will always have "notification" rights.
• Users will always have "changePassword" permissions.
• The email address for users is always required.
• Inputs that accept "resource identifiers" do not accept the "hash:STRING" format. Only "id:INTEGER" and "/path/to/file" are accepted.
• Multi-Status responses (for POST /resources/copy, POST /resources/move and DELETE /resources) are not supported. If an operation is partially successful, you will receive an error message for the first failure rather than a multi-status response. When this happens, the response will not include information about any files that were successfully processed or any files that were not attempted.
• The hash and createdby attributes for resources of type "file" is not supported and will always be empty in a returned Resource object.
• The filecount and size attributes for resources of type "dir" is not supported and will always be empty in a returned Resource object.

Changes to POST /users

• If the nickname is not specified, it will not default to the username (will be null).
• If an empty permissions object is provided, it will create a user with no permissions rather than returning an error.
• "UTC" is not a valid option for the timeZone parameter.
• The email parameter is always required to be a valid email, regardless of the user permissions.
• The welcomeEmail parameter is ignored, and a welcome email is always sent.
• Passwords cannot be set to common words or passwords which have been published on the dark web.

Changes to GET /users

• The include parameter is not supported and the included array in the response will always be empty.
• The user with the role master will be listed as having role admin.
• The homeResource filter parameter must not be prefixed with a leading slash when filtering for users having a specific home directory.
• The status filter parameter is not supported.
• The email filter parameter does not support wilcards.
• Sorting the list by nickname, username, email, or homeDir is case-insensitive.
• Attempting to list a user with a name taken by another account will result in a 404 NOT FOUND error rather than a 403 ACCESS DENIED error.

Changes to GET /users/{id}

• The include parameter is not supported and the included array in the response will always be empty.
• The user with the role master will be listed as having role admin.

Changes to DELETE /users/{id}

• There is no master user on red, so it is now possible to remove the user who has the same name as the account.

Changes to PATCH /users/{id}

• Admin users can now edit any user, including the "master" user.
• Email addresses can be removed from a user by setting the `email` to an empty string ("")
• Passwords cannot be set to common words or passwords which have been published on the dark web.
• "UTC" is not a valid option for the timeZone parameter.
• The expiration value must be in the future.
• Non-admin users cannot change their own user settings.

Changes to GET /resources/list

• The name filter cannot be used to search recursively through a folder or the entire account.
• The name filter does not support wildcard characters.
• The list of results cannot be sorted by file type (extension).

Changes to GET /resources/list/{id}

• The name filter does not support wildcard characters.
• The list of results cannot be sorted by file type (extension).

Changes to DELETE /resources/{id}

• When a resource cannot be deleted, the meta.id property in the errors array of the response will be a string rather than an integer.

Changes to GET /account

• The include parameter is not supported and the included array in the response will always be empty.
• Only administrator users can use the method to retrieve details about the site.
• The data.attributes.clientId value in the response will return null
• The data.attributes.maxUsers value in the response will return 999999999999999
• The values in data.attributes.quota will consist of placeholder values. You can no longer rely on data.attributes.quota.diskUsed to track the amount of storage space used by the account.

Legacy ExaVault API v 1.2

Supported Methods:

• GET|POST /authenticateUser
• POST /logoutUser
• POST /createUser
• GET /deleteUser
• GET|POST /getUser
• GET|POST /getUsers
• POST /updateUser
• GET /checkFilesExist
• POST /copyResources
• GET|POST /createFolder
• GET /deleteResources
• GET /getDownloadFileUrl
• GET /download
• GET /getFolders
• GET /getPageCount
• GET|POST /getResourceList
• GET /getResourceProperties
• GET|POST /getUploadFileUrl
• GET|POST /moveResources
• GET /previewFile
• POST /renameResource
• POST /upload
• GET /getAccount

Changes for version 1.2:

• Access tokens returned by the POST /authenticateUser method will be shorter than the ones returned by the legacy platform.