Dojo Bookings
Dojo bookings is a crucial part of Dojo's Restaurant Management System (RMS). It is designed to provide best in class, integrated, management tools to businesses. Dojo Bookings uses all entities within the Epos Data API to retrieve and manipulate data on the POS.
Dojo Bookings infers availability from the information recieved by the POS in near-real time, as such, the integration allows a seamless, efficient and importantly an automated way of organising bookings and directing guests to venues with availability.
Core Components
The core components needed to support Dojo Bookings
| Features | Description |
|---|---|
Orders | The Order entity represents the core component of the Ordering API, containing all relevant information about an order placed by customers at a given location. An order can consist of multiple items, each with details like status, quantity, price, and applied modifiers. Dojo products create, modify and retrieve orders on the POS via the EPOS Data component of the Dojo API. |
Parties | The Parties entity represents a group seated in the venue, and should uniquely identify them in the POS for the entire duration of their stay. Dojo Bookings infers availability by the presence of a party at a table. Each party can include additional details such as deposits, special requests and allergen information. A Table may have one party associated to it at any one time, where a Party may have multiple tables and orders associated. The partyId should be unique and not match any other current party, you may reuse ids for parties that are now deleted. |
Reservations | The Reservation entity represents an upcoming party or booking. Reservations may be created, updated and deleted by Dojo products. Once a reservation has been seated within the venue, it becomes a party. The POS may also create a reservation, however, you should be aware that the POS may not have full access to the availability and schedules set up on Dojo Bookings. Once a reservation is seated, a party is created that is linked to that reservation - but the reservation itself continues to exist (unchanged) as before . |
Tables | The Table entity represents a physical place within a location and/or area where customers are designated. Tables are mostly static, but expected to change if there are physical layout changes at a location. Tables may have multiple active orders at any one time. |
Areas | The Area entity represents physical areas within a location. Examples of areas would be "dining area", "beer garden" and "upstairs". |
Capabilites
In the Dojo EPOS Data API, capabilities represent specific actions that the POS system can perform. These capabilities are linked to corresponding API endpoints in the POS system. By defining these capabilities, the POS system communicates to Dojo which features are supported and accessible.
The below capabilites are needed to support all aspects of the Dojo Bookings integration:
Reservations
CreateReservation
This capability allows for the creation of a new reservation within the POS system. This enables the creation of bookings on the POS by Dojo products.
UpdateReservationById
PUT REST /v1/reservations/{reservationId}
This capability allows Dojo to update reservations on the POS. For example, this could be changes to the reservation's covers, time-slot or table IDs.
GetReservationById
GET REST /v1/reservations/{reservationId}
This capability allows Dojo to retrieve up-to-date information from the POS about a specific reservation such as the start-time, end-time and any booked table IDs.
SearchReservations
POST REST /v1/reservations/search
This capability allows Dojo to retrieve reservations from a POS and can include filters such as table Id and time slot.
DeleteReservationById
DELETE REST /v1/reservations/{reservationId}
This capability allows Dojos to delete a specific reservation by using the reservation Id.
Parties
CreateParty
POST REST /v1/parties
This capability allows the creation of a new Party within the POS system. It is essential for assigning parties to a table and storing relevant order details.
UpdatePartyById
PUT REST /v1/parties/{partyId}
This capability allows Dojo to update the POS with additional party information given after initial booking. For example, this could be the party's allergen requirements in the form of guestRequests, a change in booking time or a new expected end-time.
GetPartyById
GET REST /v1/parties/{partyId}
This capability allows Dojo to retrieve up-to-date information about a specific party seated at a table, such as the unique ID, table ID and status.
SearchParties
This capability allows Dojo to retrieve parties from a POS. By default, the POS should not return parties where endTime is set, including them only where completedOnly is "true".
DeletePartyById
DELETE REST /v1/parties/{partyId}
This capability allows Dojos Epos Data API to delete a specific party by using the party Id.
Orders
GetOrderById
This capability enables the POS system to retrieve detailed information about a specific order using its unique order ID. This is crucial for order tracking and status updates.
SearchOrders
POST REST /v1/orders
This capability enables searching for orders based on various criteria. It supports filtering and pagination to help Dojo products efficiently find orders within the POS system. Each Dojo product has different requirements on what filters must be implemented which can be found on the product documentation page(s).
Tables
SearchTables
POST REST /v1/tables
This capability enables searching for Tables from the POS system.
Areas
ListAreas
GET REST /v1/areas
This capability enables listing areas from the POS system.
Source of truth
The POS serves as the authoritative source for all its data. Dojo products, such as Bookings, can request to modify this data via the EPOS Data API, but the responsibility lies with the POS to invalidate any inappropriate requests.
For instance, if a Dojo product attempts to update an order via the EPOS Data API, the POS should apply any business logic validation to ensure that the order is allowed to be updated in this way.