The aim of this article is to describe the process of setting up a basic booking system for storage lockers using Hapio. First, let’s introduce a set of requirements.

The requirements

• The storage lockers are bound to a specific physical location, and multiple physical locations should be supported.

• The storage lockers are bookable day by day and are accessible during business hours. All lockers need to have their own schedule to account for specific lockers being inaccessible on certain dates.

• The schedules differ between the winter and summer (summers have Saturdays closed, and winters have Sundays closed).

• There are two types of storage lockers; one basic and one premium which has a larger storage space.

• The price of a booking is determined by the number of days that it is occupied and the price per day differs between a basic and premium locker.

• A booking should only be valid for a specific locker in a specified location.

• A booking should be cancelable.

• Customer information should be stored for each booking.

Hapio entities

Given the requirements above, let’s introduce the Hapio entities that we can use to implement this.

Locations

The location entity in Hapio is used in order to represent the different physical locations. In this case of storage lockers, the resource selection strategy is set to randomize since it’s not of utmost importance which customer is assigned a specific locker.

Services

Services in this case are used to differentiate between the basic and premium lockers. Using the type, price, and time properties it becomes trivial to set up additional services in the future for different types of lockers such as those booked for a fixed time instead of daily.

Resources

Each storage locker is represented as a resource and is in its most basic form just a name of the locker where the amount of simultaneous bookings is set to one.

Associating the lockers to services ensures that it is simple to differentiate between premium and basic lockers. It also trivializes the changes needed in the event that all basic lockers will be replaced by premium lockers.

Recurring schedule

The schedules for the storage lockers are created using a recurring schedule for every locker. Since the opening hours are different between summer and winter two schedules need to be created for every resource. The summer schedule starts at the beginning of May to the end of August, and the winter schedule starts from the first of September until the end of April.

Recurring schedule block

For each schedule, recurring schedule blocks are used to set up the different opening hours for each day of the week. The opening hours determine where bookings are allowed to be created for the resource. For the summer schedule, it’s all full days besides Saturday, the winter schedule is all full days besides Sunday.

Bookings

A booking is an association between a resource and a service for a specific location within an available time in its schedule.

The built-in support for storing any valid JSON using the metadata simplifies the mapping between different systems in order to get all information necessary from a booking, together with the innate support for cancellation and temporary bookings making the booking entity extremely flexible. Furthermore using webhooks for booking events allows for highly customizable and seamless integrations with other systems.

Using Hapio

With the necessary entities set up, it’s time to look at how to leverage the full power of Hapio to get started with the booking process.

One of the most common operations is to find which time spans are bookable for a given service in a specific location. Hapio trivializes the operation by exposing a single endpoint to fetch all bookable slots for a given service in a specified location, with the option to return only slots from a specified resource. In the case of the locker system, which locker a customer is assigned is of less importance, so there’s no need to specify a resource when fetching bookable slots.

The list of bookable slots given above includes all time spans that are available for the given service. Every slot contains its start and end times together with a list of available resources for the allotted time. Using the slot it is then effortless to create a booking for the service with the start and end times and if needed specify a resource to cover the slot. If no resource is specified for the booking Hapio automatically assigns a resource based on the resource selection strategy of the location.

The support of the metadata property on some of the entities makes it trivial to map the Hapio entities to other business entities and comes with the added benefit of having full control when making custom seamless integrations with other systems.

Hapio’s API-first approach allows for utmost flexibility since it can just as easily be consumed by mobile applications as it can be web applications. Furthermore, Hapio comes with the added benefit of not requiring the user to switch between multiple systems in their day-to-day work, since Hapio is easily integrated within one’s own administrative dashboard.

Benefits of using Hapio

The requirements were easily solved using Hapio’s built-in entities. By outsourcing the booking process to Hapio, countless hours need not be spent on developing a fully-fledged booking system and your development can be focused on other business values and perfecting the customer experience.

Hapio’s support for webhooks makes it effortless to respond to changes within the system which in turn allows for a highly customizable booking system integrating with one’s favorite systems.

Are you interested in integrating Hapio into your system? Get started now!

Use case

Use case: Booking of storage lockers