Anatomy of a Custom App
Before you start
- You need access to the Control Panel with permission to manage the App Development Kit.
Note: Examples in these pages are samples, not officially supported by Interact Technical Support, and should be reviewed and tested by your development team before use.
Overview
The ADK gives you flexibility when you build your Custom Apps. This page explains what is required to build one.
Front-end code
Custom Apps are injected into the front end of your environment at run time and evaluated after the initial page load. This means you have access to fully initialised context and do not need to worry about asset loading.
Using the management interface (Control Panel > App Development Kit > Add Custom App), you can add markup that includes HTML, CSS and JavaScript. This forms the basis of Custom Apps.
A Homepage Admin can then add these apps to any homepage.
Session state
Ambient state is available within the context of Custom App front-end code. Access it through global JavaScript variables, with a primary entry point of window.interact.
Examples include:
- PersonID — the Interact ID of the current user
- ThemeID — the theme GUID for the current user
- Language — the IETF language code for the current user
Theme variables
Alongside information about the current user and session state, the active theme exposes a large number of CSS variables for use in your Custom App.
For example, to use your primary brand colour to style a button, you could use the following code:
button {
background: var(--primary-brand);
}
For a full list of the theme variables, inspect the :root object in your browser's developer tools, as the available variables are constantly expanding.
APIs
The public APIs are documented on this site, so use the search function to find specific endpoints. Many endpoints are available that are not publicly documented. If you have specific use cases that you believe may be supported but not documented, contact Interact Technical Support for more information.
Back-end code
We recommend using only front-end code as part of the ADK, to ensure:
- Security — browsers enforce strict control over access to native APIs and data, as do the REST APIs. Back-end code with complete access to data storage and more can pose elevated security risks.
- Performance — errant code, such as an infinite loop running for a single user, could have a knock-on performance impact on your environment.
If credentials need to be passed to other systems, use a proxy service to handle the call, such as a function in AWS Lambda, Azure Functions or a similar system. Credentials can then be stored securely, and the ADK application calls these functions and retrieves only the data.
Tip: To discuss this approach in more detail, contact your Customer Success Manager to set up a call with the Technical Services Team.