Webhooks - Anatomy of a webhook plugin

If you haven't already, I would encourage you to read the Webhooks Introduction page so that you have an idea of what a Jomres Webhook plugin does. If you are interested in creating Jomres plugins in general, then a good place to start is the Hello World plugin example.

This page does not teach you to code. Instead it is designed to give you the basics of a Webhook plugin's structure so that experienced developers can quickly create their own plugins for sending information from Jomres installations to remote services when certain activities are performed.

As a result I will skip looking at the code itself. If you want to make your own webhook plugin I recommend that you install the "Webhooks Authmethod None" plugin in the Jomres Plugin Manager, then you can compare this guide to the files, and potentially use that plugin as a foundation for building your own code. It's released under the GPL so you are free to copy and adjust those files as needed.

Like almost all Jomres plugins, functionality is provided through Minicomponents. For a summary of the Minicomponent trigger numbers, see this page on Github.

webhook plugin files


There are 4 files in this plugin. You could of course your own class files if needed, but they might not be required.


All Jomres should have a plugin info script. See the Hello World example mentioned above for more information on them.


This script is run whenever Jomres is run and it is used to include the language file in the /language/ sub-directory.


This script is used to tell the webhook page that a certain webhook exists, and what language strings and settings it uses. This information is used both on the New Webhook page and when you change the Authentication Integration dropdown on that page.


When an action is performed in Jomres, and Jomres finds that there is a Webhook or Webhooks for that property's property manager, then the webhook handling is triggered, and the appropriate script is called to process the action.

This script is given the action's information and it's this script's responsibility to authenticate with the remote site, using the previously stored login information, and to send the body of the action that was performed.