Skip to content
Riversoft STCP DirectLink API
Migration to v2

Migration from v1 to v2

Starting with Riversoft® STCP DirectLink 9.0.1, the Riversoft STCP DirectLink API is served only in version v2, with the /directlink/v2 prefix. Version v1 is no longer served. Adapt your integrations before the environment is upgraded.

What changes

Change in v2What to do in the integration
/directlink/v2 prefix on all routes.Replace /directlink/v1 with /directlink/v2 in the URLs.
Upload, listings, report and logout require a Bearer token, in the Authorization header or in the session cookie. Basic is accepted only on /auth/login.Obtain a token and send Authorization: Bearer <token>. See Authentication.
Downloading a listed file (/download/file and /download/file/backup) requires the linkURL and the Bearer token or the session cookie of the same user who made the listing.Send the same token used in the listing when downloading the file. See Receive files.
/auth/token and /oauth2/token are equivalent and issue tokens by password grant or token exchange, according to the methods enabled in the environment.Check the enabled methods with the administrator. To follow OAuth 2.1, prefer token exchange. See OAuth tokens.
In token exchange, the JWT provider is given in the provider field or in the X-STCPDIRECTLINK-JWT-ISSUER header.Give the provider in each token request.
The portal and SSO session is kept in the secure __Host-dirl_session cookie. The token is no longer delivered in the URL.Use the cookie session or a token obtained from the token endpoints.
Calls made through a host other than the configured one are rejected with 403.Use the address configured for the API.
The time field of responses uses the ISO 8601 (RFC 3339) format, for example 2026-11-07T14:03:21-03:00.Adjust how this field is read.
/auth/change accepts only POST; other methods receive 405.Send POST with p and z in the form body, never in the URL.
The apiver field reports v2, for example v2 (9.0.1).Adjust validations that check the version.

The shared link (/download), delivered to third parties with or without a PIN, still works without a token.

How to migrate

Survey the integrations

Identify the systems that call the API, the routes they use and how each one authenticates today.

Change the prefix

Change the base URL to https://{host}/directlink/v2.

Adjust authentication

Obtain a token by login, token exchange or password grant (when enabled) and send it on all protected routes, including the download through linkURL.

Adjust response handling

Update how the time and apiver fields are read.

Test in a staging environment

Test sign-in, upload, listing and download, report and logout before the production environment is upgraded.

Checklist

  • All URLs use /directlink/v2.
  • All protected routes send the Bearer token or use the session cookie.
  • The download through linkURL sends the token of the same user who made the listing.
  • The time field is read in the ISO 8601 format.
  • The authentication methods in use are enabled in the environment.
  • The host used by the clients is the one configured for the API.

For the server upgrade procedure, intended for administrators, see Migration from version 8 to version 9.

QuickstartSecurity