Skip to content






Service manager

API Explorer

Integrate package properties

Sometimes you may find it useful to store certain values for later use in your services. If this is the case, you may need the help of properties!

In TORO Integrate, we have properties that are global to the instance or local to a certain package. You'll want to use package properties if you want certain values to be persisted and shared across a package and that package only. A typical use case would be storing API access keys; when you use a third-party API, you would typically use the same set of credentials to access any of its secured services.

Your package properties are stored in a file called under your package's conf/properties directory by default. But if you wish, you can have other prefixed files under the same folder and have your instance select which one to use via the package.prefix instance property.

Might have to manually create the files

Your .properties files are not automatically generated when you create a package or when you re-specify the value of package.prefix. If your .properties files are missing, simply create them under the conf/properties folder.

Package .properties files used to be just in the root conf directory

TORO Integrate's v3.1 release changed the location of these files for better organization.

Properties you put in <package.prefix> will override those written in, provided that you are using the same prefix set in package.prefix. However, that's not to say the key-value pairs in are gone or ignored. <package.prefix> simply take higher precedence and its key-value pairs will be used whenever available. If a key is not present in the prefixed file, TORO Integrate will fall back to using the same property in This offers more convenience than you think! For packages that need to use a different set of package properties for development and production environments, the switch will be smoother!

Follow the naming convention

Deleting or renaming your or <package.prefix> file to something unconventional will make it unrecognizable to your instance and thus, you lose all your key-value pairs.

Like instance properties, changes to your package properties will be visible as soon as you save the properties file; and likewise, depending on how you use these properties; they may or may not take effect immediately and in the times that they do not, a package restart may be required.

Modifying package properties via Coder

To add new properties via user interface, follow the steps below:

  1. Go to the Coder Navigator view.
  2. Look for your package and expand its contents by clicking on the arrow heads. Look for the conf directory,
  3. Double click the .properties file to open it.
  4. Add, edit, and remove key-value pairs as needed.

    Opening the `` file

    Opening the `` file

Quick search for files

In Coder Studio, you can do to search for your .properties file(s) instead using the Open Resource dialog. With this, you can optionally open all of your .properties files all at once.

Searching for `.properties` files via the Open Resource dialog

Modifying and using package properties programmatically

The instance-wide classloader ships with a Groovy extension module packed with utility methods. This means that you can use the functions defined in that extension module in all of your Groovy or Gloop code.

When working with package properties, most, if not all, of the methods you'll be needing are present in the GroovyMethods class.

You can add or modify package properties in Groovy code by using some of the methods provided by the extension module mentioned above:


Array values

If you want to save an array of values, simply create a string of all the values separated by commas. We have utility methods that'll parse and split those values up for you and return them in an array.

To remove a package property, do:


To fetch the value of a package property, you can do any of the following:

'key'.getPackagePropertyArray(['default-value-one', 'default-value-two'])

The methods for managing package properties are context-aware. If you call any of the methods above in a certain script and that script is contained in a package called foo, then only foo's package properties will be fetched, added, modified, or removed.

The one-liner will take this precedence of retrieving/saving the property from/to your properties file:

  1. From your prefixed package properties file (if package.prefix is set and the <package.prefix> exists)
  2. From the file
  3. From your instance properties