Intro Plugin Structure Categories Static Actions Action Data Dynamic Actions States Events Connectors Settings Notifications Reference Troubleshooting Example SDKs

Touch Portal Plugin API

You are about to create a plugin for Touch Portal. On this page you will find all the information required to make an awesome plugin!

The menu on the left can be used to navigate to all sections explaining the plugin system. Start with "Structure"

The Plugin Description file

The whole structure of the Touch Portal plugin system revolves around the plugin description file. This is a JSON file describing the plugin named 'entry.tp'. Touch Portal loads this files and with the given data, it will create action categories, actions, events and states within Touch Portal.

The plugins have to be placed in the plugin folder in your Touch Portal user data folder.

%appdata%\TouchPortal\plugins\(unique plugin folder name)\

Or for our early adopter users it can also be that the user data folder is in the documents folder of the windows user.

C:\Users\(window user name)\Documents\TouchPortal\plugins\(unique plugin folder name)\

Or for mac users

\Documents\TouchPortal\plugins\(unique plugin folder name)\

All the plugin files can be placed in this folder but they do not have to be. The root, however, must contain the entry.tp file.

Creating a plugin file .tpp

We encourage plug-in builders to create their own installer as often the plug-in requires to install more then just the entry file. Touch Portal supports a limited install file type with the extention .tpp.

The tpp file should be a renamed zip file containing the root folder that has the name of your plug-in. In that folder you should place the entry.tp file and possible additional files you want such as the icon for the plug-in. Just do not forget to rename the zip file to the extension .tpp.

To ensure stability in the Touch Portal environment you need to understand the following:
  1. Everytime you have made a change to a plugin during testing, this needs to be loaded fully in Touch Portal again to see the changes. The only way doing this is to fully close Touch Portal and restart Touch Portal.
  2. All actions that are created from a plugin are stored fully locally. This means there is no more dependency to the plugin. This also means the action can survive when the plugin is removed as all information is stored in the button. This does not count for endpoints off course for dynamic actions but the calls to that endpoint are still present. This also means that during testing when you make changes to an action, the action needs to be removed and re-added to see the change have effect.