Using v1.2 authenticateUser with Legacy API Keys

API Keys that were migrated from the legacy ExaVault platform are site-wide keys within your Files.com account.

Using a Migrated v2 Access Token

Access tokens that were created in the legacy ExaVault web application were migrated to your Files.com site as user API Keys.

Using Files.com API Keys

You can create new API keys on your Files.com site and supply those to the legacy ExaVault API.

If you create new API keys, your API code cannot use https://api.exavault.com as the base URL.

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):

For an application that is using the v1.2 authenticateUser function to create a session, you can provide a Files.com site-wide API Key in the api_key header for all v1.2 requests.. xaV

Once you have received a token from the authenticateUser function, supply that token in the access_token request parameter for v1.2 requests. For v2 requests, you can supply that token in the ev-api-key header and the ev-access-token header.

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

If your application does not generate a new session via the the v1.2 authenticateUser function, you can instead provide a Files.com user API Key for all requests to the legacy ExaVault API.

If you are making a call to a v1.2 function, supply the Files.com user API Key in both the api_key header and the access_token request parameter.

For calls to a v2.0 function, provide the Files.com user API Key for both the ev-api-key header and ev-access-token headers.