A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application. The term "webhook" was coined by Jeff Lindsay in 2007 from the computer programming term hook.
This feature is currently under development.
Jomres offers Webhooks that can inform remote services that certain actions have been performed in a Jomres installation. This feature should be considered as a companion to the API functionality, which receives messages from remote services. Together the two systems can be used to facillitate communications between systems that don't require direct actions by users.
The Jomres implementation of this feature consists of a number of plugins.
Allows Property Managers to create "Integrations" which are configured to supply a URL and can optionally be configured with various authentication parameters.
Webhooks Collection Library
Contains a library of scripts that Integrations use to collect data that's then sent onwards to remote services.
Webhooks Authentication Methods (Auth Methods)
These contain both the configuration parameters for the Integrations, and the scripts that are called when a remote service is to be called using those integration settings. To date three authentication methods are available :
- None. This refers to the fact that the remote server doesn't require any authentication. Data is POSTed to the remote service in JSON format.
- Basic. This Authentication Method support Basic Access Authentication. Data is POSTed to the remote service in JSON format.
- Oauth. The Authentication Method is able to call Oauth2 services that can authentication via the "client_credentials" grant type. Data is POSTed to the remote service in JSON format.
Webhooks Core is the method by which users interact with the Webhooks feature, configuration Integrations. It also supplies the code that caused the Authentication Method's processing scripts to be called. The Collection Library (CL) supplies a basic set of features that can be used by the Authentication Methods however the feature has been built in such a way that the Auth Methods don't need to use the CL. Essentially the CL supplies some basic functionality to collect information after a change has been made in the system, which the Auth Methods can use or not as required, allowing code re-use.
Whilst initially we will distribute the three ( none/basic/oauth ) Auth Methods, developers aren't limited to just those three. A developer can write their own Auth Method that can send it's own selected data to a remote service. The developer can use the CL to crib from to learn how to pull data from Jomres to prep for sending to the remote service.
I am planning to write at least one more Auth Method, for Jomres2Jomres calls ( will require a corresponding API Feature to be installed on the remote site ) that will allow one Jomres site to update another in a Master to Slave format. The architecture also allows us to update Channel Managers using Auth Methods.
TODO : Message Queuing & Allow managers to select specific tasks for different integrations.