web hooks

send a message to another server or system - requires paid plan

How does it work?

Your development team would need to identify service which is already listening out for messages from us. Then they would enter the location of this listener - and the fields for us to include - in the webhook setting for your profile. Our system will try to send this signal on each new booking.

Why Do You Need It?

Perhaps your organization has some internal server systems that need to be kept informed about any bookings as they are made. It will probably also want to hear from us when someone cancels.

How to use this feature

This is an advanced feature that we recommend you use only if you are already familiar with the concept of 'web services' and 'APIs'.

To begin with you need to identify the service or listener which will be taking our signals. Perhaps you have an internal Customer Relationship Management (CRM) tool that would like to know each time a booking is made. It might be that your development team have already set up a listener on a particular URL owned by your organization, e.g.:


This will probably be expecting some variables to be passed in. Say they need to know the email address of the person (to track down any existing record on your database) and also the date and location of the appointment. In this example, they would be looking for three variables : "email", "starttime" and "location". Here's how a filled out URL might look when calling the service:


This is of course just an example. There's a huge range of different kinds of listeners that could be messaged this way.

Here's what you would need to enter into our webhook setting to send this kind of message:

Hopefully you can see how our mail merge feature can be used to build these links to include whatever information you need to pass through.

HTML form webhooks

Building up a URL webhook in this way can be a neat and simple way to work, but if you have a very large amount of data to include, it can quickly get quite fiddly. There's another option that might make it simpler.

Here the starting point would be an online form somewhere which was all set up to trigger your listener. Our webhook box is happy to take the raw HTML of your form as a simple way to specify the format of the signal. Here's how this would look, using the above example:

There's a couple of advantages to working this way. First is that you can get started by testing your listener with a webform online somewhere and - once you are sure all the data items are being passed through correctly - simply copy the HTML for the form into our box. This means you can be sure you have the right action and field names. The only step you need to do is add in the mail merge fields into the value attributes.

The other advantage is that you can specify a POST method, rather than the GET which is the default for simple URL based webhooks.

Running the webhooks

Once you are all set up, just make a test booking to see the webhook get triggered. It happens asynchronously on our servers, but the signal will always be started within a few seconds of the booking being confirmed.

If your server replies with a 200 status signal (i.e. that the http request was successful) no further action will be taken by our server. But any other kind of response (e.g. a 404, or error message from the server) our systems will build an email report for you setting out what happened.

This advanced feature can be used to signal to another server or system whenever a booking is made or cancelled.