Webhooks provide a simple way to integrate CloudBolt with external systems that expose a web-based API (typically REST based APIs). Example usages include posting a message to a chat room every time a certain blueprint is deployed, creating an entry in a CMDB when a new server is built, and enabling/disabling monitoring when a user clicks on a button on the server details page.

Webhook Fields

In addition to the common fields (name, description, etc), webhooks have the following fields:

  • URL - the web address that CB will POST to when the webhook is executed.
  • Authentication method -
  • HTTP basic auth - if chosen, a username and password should also be provided.
  • Token-based auth - if chosen, a header name and value should be provided. Check the docs of the external API to determine what HTTP header and value they expect. HipChat’s API, for example, expects a header called Authorization with a value of Bearer  <your HipChat API token>.
  • Content type - The expected type for payload. Defaults to “application/json”.
  • Payload - JSON-formatted data to pass in the body of the request.
  • Custom headers - JSON object where keys are HTTP header names and values are header values. Ex. {'user-agent': 'my-app/0.0.1'}. There are certain headers that cannot be overridden, for more information see http://docs.python-requests.org/en/master/user/quickstart/#custom-headers.

Webhook Parameterization

When creating or editing a Webhook, CloudBolt will parse the URL, Payload, and Custom headers attributes looking for template style variables like {{ variable }} and will automatically create action inputs for each variable it discovers. See Action Input Parameters for more details on auto generated action inputs and Action Context for a complete reference list of objects available to Webhooks on different contexts.


When CloudBolt executes a webhook, it makes an HTTP post to the specified URL. If the return code is between 200 and 299, it is considered a success, otherwise it is treated as a failure. The HTTP return code is shown in the job progress and the body of the message that is returned by the web server is written to the log for the CloudBolt job (if the webhook is running in the context of a specific job, otherwise the log messages go to application.log).


It’s worth noting that everything webhooks do could also be accomplished with a CloudBolt plug-in. The webhook type exists primarily to remove the need to write code to integrate with external systems, making these integrations easier to create and maintain. However, if you need to perform other logic around a call to an external API (ex. to only call the API if certain conditions are true, or process the results in a specific way), you can always write a CloudBolt plug-in for this and use the Python requests library to make the HTTP call.

As with all CloudBolt features, if you have questions about it or want it to do more than it does, contact us at support@cloudboltsoftware.com.