You can setup and configure booking widgets through our admin panel, but the widget has many more "hidden" options than what meets the eye. Let's have a look at some of them!
Setup on your page
If you setup a booking widget through our admin, you can generate an embed that looks something along these lines:
<div id="bookingjs"></div>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js" defer></script>
<script src="https://cdn.timekit.io/booking-js/v2/booking.min.js" defer></script>
<script>
window.timekitBookingConfig = {
app_key: 'live_widget_key_yYXHsUurvCUctNYflzGDMqEJo6mol0Yo',
resources: []
}
</script>
Here's what happens when you paste it on a webpage:
jQuery is loaded & the widget library is loaded from our CDN servers
Based on the unique app_key, it will fetch the corresponding config from our servers with all the settings you made through our admin
If you supply additional config settings, it will merge them into the config it got from our server above. This means that you can overwrite or add extra settings to the booking widget through code!
The booking widget is rendered in all its glory
Step #3 is the key here. Let's explore how this works.
Adding additional config settings
First, go ahead and check out our readme for booking.js on Github - it serves as a reference for all possible options you can throw at it.
Now, do you see the window.timekitBookingConfig part in the example above? This is a JavaScript object that contains configuration settings that the project widget will use.
Let's start off easy by changing the display name that's shown on the booking widget header:
<script>
window.timekitBookingConfig = {
app_key: 'live_widget_key_yYXHsUurvCUctNYflzGDMqEJo6mol0Yo',
resources: [],
ui: {
display_name: 'Martys Timetravel Service'
}
}
</script>
That's it! Even though you already specified a display name through our admin, the value that you provide here takes precedence, i.e. "Marty McFly" is shown.
Passing extra parameters to the API calls
The booking widget is essentially just a pretty UI that calls our API for data. The API requests are handled by the widget internals, but you can specify extra parameters that should be sent along the requests.
Does this sound like gibberish to you? Here's an example of how to use the from parameter of our availability endpoint to specify from which point in time that the availability algorithm should start to look for timeslots:
<script>
window.timekitBookingConfig = {
app_key: 'live_widget_key_yYXHsUurvCUctNYflzGDMqEJo6mol0Yo',
resources: [],
availability: {
from: '3 days'
}
}
</script>
The above will ensure that you have 3 days of buffer time before available timeslots are shown.
Common use-cases
There's quite a lot of "hidden" features you can unlock with this approach. Here's some of the most popular:
Add additional booking fields to the form
Change the button and success message text
Disable the confirm/booking page entirely and add your own
Hook into callbacks and perform actions based on interactions (e.g. call your server whenever a booking is successfully made)
Most of the above is already documented in the readme for booking.js on Github but we're working on more easy-to-digest articles that explore each of them in detail 🙌