HTML and EMail Templates

HTML Templates

Activation pages

When activating a new TeamDrive installation, an activation link is sent to the user. The activation link will direct them to the Registration Server (or another server that is using the API to activate the device using an API call). Each Provider has their own activation pages, so that they can be modified to the CI of the Provider. The templates are copied to the apache root document during the setup of the Registration Server and when adding an additional Provider. However, they can still be modified afterwards.

A typical path looks like this:


The link to the activation pages will be created using the ActivationURL (see ActivationURL), the provider information, the language of the user (if it’s part of the allowed languages, see EMAIL Settings (<Email> XML block) and ACTIVATION Settings (<Activation> XML block)) and the page itself.


The Provider Code (like “TMDR”) in the file system will be converted to lower case in this case.

There are different pages which are nearly the same.

The success page is:


<platform> can be win, mac, linux, ios, or android

Error pages are:

  • already.html: Link was already clicked and the device is activated
  • error.html: Unexpected error occurred
  • invalid.html: Activation code invalid (length != 32)
  • notfound.html: Activation code not found

Email pages

Changing an email address will send a notification email to the old email address, informing the user the new address is being set for the account, and an activation mail to the new email account. The user must click the activation link in the activation email to confirm the change.

The success page is:


The error pages:

  • error.html: Unexpected error occurred
  • invalid.html: Activation code invalid (length != 32)
  • notfound.html: Activation code not found

Email Templates

There are two different template categories. The templates starting with “web-*” in the file name are triggered by actions from the API. All other templates will be triggered by actions from the TeamDrive Client.

There are templates for English and German available. The language in the filename is located at the last part of the filename (example: Additional languages can be added by creating a new file with a new language code.

Each Provider has their own set of templates, so that each Provider can use their own text and graphics in the templates. Each Provider has to define the available and allowed languages in their Provider settings as described in EMAIL Settings (<Email> XML block).

Templates can be all plain-text or plain-text with an HTML part. By default, the invitation templates have a text and an HTML part. All other templates are completely in plain text. All templates can be modified by you.

The notification mails for spaces or files can not be modified. This mail is directly generated by the teamdrive clients and can not use a template.

Structure of the mail templates

Text mail: The subject of the email will be divided using these two characters “//”. Everything before will be used as the subject. Everything behind is the mail body.

HTML mail: The structure is a little more complicated (see, because for mail clients which do not display HTML you have to offer a plain text part. Otherwise the email will be shown as empty within this mail client. The template is divided into several parts. Replace the place holders with your content:

  • Definition of a multipart-mail (the boundary string will be used in the following text and HTML part):

    Content-Type: multipart/alternative; charset=UTF-8;
  • followed by the subject (divided by “//” again): //TeamDrive invitation//

  • followed by the text and HTML part:

    Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
    Content-Transfer-Encoding: 8bit
    <Put in your plain text here>
    Content-Type: text/html; charset=UTF-8;
    Content-Transfer-Encoding: 8bit
    <put in your HTML code here>

Templates for Client actions

The product brand name, defined in the provider-specific setting EMAIL/BRAND_NAME. If not set or empty, the default is “TeamDrive”.


  • reg-activationlink: This will send an email with an activation link to the user. They can only proceed with the registration by clicking the link within the email. The link must lead back to your server, so that the activation code can be verified. There are three fields available which will be replaced before the email will be send to the user:

    [[SERVERURL]]: This is the URL defined in the xml file as described in RegServerURL. You can also replace it with an other URL which also points to the Registration Server. If you prefer to use an own page, you can use the Registration Server API which can also activate an installation.

    [[SERVERPATH]]: The script name (“pbas/td2as”) of the internal module which handles the activation requests.

    [[ACTIVATIONCODE]]: This is the activation code of a non-activated installation. The code is unique for each new installation, and is used for verification by the server.

    [[DISTRIBUTOR]]: The Provider Code, which will be used to redirect to the success or error page (which are defined as described in HTML Templates).

  • reg-notify: By default, only the first installation must be manually activated (depends on the setting described in AllowActivationWithoutEmail). The user will just receive a notification mail that an additional device was installed

  • new-passwd: If the user lost their password, they can reset the password during the login process (see Forgotten password for details). There must be one field in the email which will be replaced before the email can be send:

    [[NEWPASSWORD]]: Only a temporary password will be send, which must be entered in the client together with some new password as specified by the user. Retrieving a new password also depends on the setting as described in AllowPasswordChangeInClient.

    Changing both password and email at the same time is not possible. If the email is different, this has to be changed before the password is changed.

  • reg-emailchangedtonew: Upon requesting an email change, the user will receive an activation URL to verify that the new email belongs to him. The following fields are available: [[SERVERURL]]: The same as described above in reg-activationlink [[SERVERPATH]]: The same as described above in reg-activationlink [[EMAILVERIFY]]: An verification code like the activation code in reg-activationlink [[DISTRIBUTOR]]: The same as described above in reg-activationlink

  • reg-emailchangedtoold: Whenever the user’s email is changed, a verification email is sent to the old address (to protect the user against potential hacking attempts). The following fields are available: [[NEWEMAIL]]: The new email address of the user

  • td3-privacyinvited-email: If a new user was invited who currently had no account, they will get an invitation sent to their email by the person who invited the user. A download link for the client application should be in this template so that the user can download and install the client. There are two new fields which have the same content, but have different line breaks: [[INVITATIONTEXT]]: The invitation text the user wrote in the client application. Line breaks are carriage return [[INVITATIONTEXTHTML]]: The same text, but line breaks are HTML conform <br> [[DOWNLOADLINK]]: Download link taken from the download Redirect-URL page as described in REDIRECT_DOWNLOAD.

  • td3-privacyinvitedsecure-email: Same as above, but with the additional mechanism that the user has to type in a password to accept the invitation. The password will be defined by the user who send the invitation. (This is an additional security option to prevent anyone from accidentally inviting an invalid user)

  • td3-privacyinvited-user: Nearly the same as an invitation by email, but the user already exists and therefore they get invited via their username.

  • td3-privacyinvitedsecure-user: Before acceptting the invitation the user must enter a password (as specified by the sender).

  • reg-storageincreasedinvited: This mail will be used if you use the user referral functionality. Each new user which is invited, as well as the inviter, will get additional storage space. Configuring this functionality is described in REFERRAL Settings.

    This template will be send as a confirmation mail to the user which was invited. You can use the following fields: [[USERNAME]]: The username of the invited user [[REFUSER]]: The username which invited the new user [[STORAGEINCREASED]]: The amount of storage which was added to the account.

  • reg-storageincreasedinviter: This template will be send as a confirmation mail to the user which invited the new user. You can use the following fields: [[USERNAME]]: The username of the user who invited a new user [[REFUSER]]: The username of the user which was invited [[STORAGEINCREASED]]: The amount of storage which was added to the account.

Templates for API actions

The API also sends emails (this can be disabled, see API_SEND_EMAIL (<APISendEmail> tag)).

The links within the templates must be point to a page where you call an API function again. For more information see the Registration Server API documentation.

  • web-activationlink: Nearly the same as described above in reg-activationlink.
  • web-delete-user: Deleting a user will delete all devices. Licenses (if defined) and all Spaces (if defined). So the user has to confirm to delete all his data.
  • web-emailchangedtonew: Nearly the same as described above in reg-emailchangedtonew.
  • web-emailchangedtoold: Nearly the same as described above in reg-emailchangedtoold.
  • web-newpassword: Nearly the same as described above in new-passwd.