File and folder structure

Navigate your local collection module folder with confidence


This guide will introduce you to the different files and folders you will find within your collection module folder when you clone a collection module from Root (or from GitHub).


This config file represents your collection module's basic setup and settings.

collectionModuleKeyString. The unique key used to identify your collection module across Root.

To link a collection module to a product module, you need to update the .root-config.json in the collection module with this key in the collectionModules section.
collectionModuleNameString. The name of your collection module.
organizationIdString. The UUID of the organisation that owns the collection module.
hostString. For most collection modules, this is (UK multi-tenant)"" (South Africa multi-tenant). If you have questions about this property, please contact support at [email protected].


This file contains your API key, which authorises you to pull and push collection module changes to Root. Your API key needs to be included in this file as follows:


When you clone a collection module from Root to your local machine, this file will automatically be included in the folder.

However, if you are cloning a collection module from GitHub, this file will not be included, as it is listed in the .gitignore file, which tells git to ignore it. In this case, you will need to create the file yourself and add a valid sandbox or production API key created under the organisation that owns the collection module.

You can add a README file to a collection module to communicate important information about the project. This file can contain information such as:

  • What the product is
  • Who the client, underwriting insurer and IP owner are
  • Links to any related files on Google Drive
  • Who maintains and contributes to the project
  • What are the outstanding tasks still to complete in this module


This file contains all of the render functions. Read more about how these work in Rendering UI Components


This file contains the processWebhookRequestfunction. This function handles webhook requests, typically from payment providers like Stripe.


This file handles the configuration for the project. This is where your environment variables and configuration will live.

You are free to update this to suit your requirements.



Type checking in JavaScript

By default, we add a VS Code setting to your collection module code directory to enable type checking. This allows you to leverage some of TypeScript's advanced type checking and error reporting functionality in regular JavaScript files - a great way to catch common programming mistakes.

These type checks use the type declaration files included under code > types and code > unit-tests > types.

To turn off type checking, open the relevant jsconfig.json file and set compilerOptions.checkJs to false.

This folder contains your collection module code. Most of the collection module code will live within handlers called from the webhook-hooks.ts file. This file handles

The collection module code consists of multiple JavaScript files. These files are compiled into a single distribution file when uploaded to AWS Lambda.


Split collection module code into separate files

You can use the collection module code files to organise your code into logical sections. For example, you can include the code for each hook in a separate file, with a further file for helper functions.

You are free to add or remove code files to suit your requirements.


The controllers folder houses the root-event-processors, and will often be where you place your payment provider processors as well.

Other files and folders

The .gitignore file is only relevant if you use GitHub to collaborate with others on a product module. This file ensures that your secret API key is not uploaded to GitHub.

The .vscode folder is used by VS Code's IntelliSense feature to generate Root-specific code snippets.