Lab Notes

Wrangling the Booker API for The Ten Spot

Posted by Dan on October 3, 2016.

We recently launched a rebranded site for The Ten Spot, a beauty bar with locations across Canada. The new design rolled out on The Ten Spot’s tenth anniversary, trading the dark palette that they were using previously for a light, airy vibe.


At Helios, WordPress is our CMS of choice and—at The Ten Spot’s request—we created a child theme to piggy back on the popular Avada WordPress theme. Avada comes chock-full with customization settings that did a lot of the heavy lifting so the bulk of our development energies were spent on The Ten Spot’s big ask: letting guests book appointments and buy gift cards through their website.

Previously, when a user hit the “book now” button, they were redirected to a third party web app hosted by It worked, but The Ten Spot wanted to have a seamless look and feel. This meant coding up a custom front end that interacted with the API.

The first step, before writing any code, was to submit a detailed workflow diagram to Booker. It had to illustrate each step in the UX (User Experience) along with all the requests that our app would make to the Booker database. The .pdf we submitted ended up being thirteen pages long and included everything from user login/signup to appointment confirmation to checkout for gift card purchases. That document made it clear that this section of the website was an entire app in itself.

About five minutes after we sent off the workflow document we got an email back from Justin, our support rep, walking us through every single API call for every view. I don’t know how he was able read our document, figure out which of the 400+ API methods to use where and send back a detailed description for each step in that short time. (Justin and I would get to know each other very well through the course of this project). He also set up a test environment for the Ten Spot account. It was time to roll up our sleeves and dig in.

There were a lot of choices to be made about structure, languages, potential frameworks, etc. Ultimately, no extra libraries or plugins were added. We went with what WordPress has in its core and created a simple JavaScript front end that communicates with the server via AJAX.

Working with the Booker API has its pros and cons.

On one hand, the documentation leaves a lot to be desired. The docs require a login that expires extremely quickly so credential need to be typed in pretty much every time a developer wants to look something up. Once the correct page is accessed, none of the query parameters have descriptions, which creates a lot of guesswork.

Also frustrating is that the Booker system requires users to be associated with a specific location. That is fine, but there is no way to query for which location a user selected. So to do certain tasks, like update their password, the guest needs to remember and enter the location that they used when they first signed up.

On the other hand, Booker support—always Justin—would respond to any questions at lightning speed. It got to a point where I would just email as soon as I got caught in any snag. In any case, the 400+ API methods mentioned earlier does give clients the flexibility to integrate the Booker system in almost any way they would like. On guests are able to book, manage and cancel their appointments without leaving the site.

The launch went very well aside from a couple DNS hiccups. The only issues we’ve run into since have been due to edge cases in legacy user accounts.

I think that this project ended up being a bit bigger than expected but we’re very happy with how it turned out.