Flows
This section covers the step-by-step flows to integrate with Dojo Bookings
Where an action is taken on the POS or Dojo Bookings, there is an expected action to update the other system. This API is bidirectional to allow both parties to be in sync in near real time.
The step-by-step guides below change depending on which flow diagram you are looking at. RMS to POS indicates the action was taken on Dojo Bookings platform, whereas POS to RMS indicates the action was taken on the POS.
- RMS to POS
- POS to RMS
This flow diagram demonstrates how Dojo Bookings will interact with the POS system for seating guests, when the action of seating them is performed on Dojo Bookings software
Step 1: Reservation is made ahead of time
A reservation is made ahead of time by a customer using Dojo Bookings platform. This reservation will be sent to the POS on the day the reservation has been made for, containing information such as reservationId, startTime and tableId
Step 2: (Optional) There is an update to the reservation
PUT REST /v1/reservations/{reservationId}
The customer has the ability to amended their booking, if they update details such as startTime, covers, they have additional guestRequests or a new tableId has been assigned. Dojo bookings will send this to the POS ahead of time ready for the guests to arrive.
Step 3: Reservation is seated using Dojo Bookings, creating a Party
POST REST /v1/parties
Once the guests arrive, the venue hosts seats them at the predefined table. Once seated, Dojo Bookings will generate a dojoPartyId and use the createParty endpoint to update the POS, this request will contain the reservationId so it can be easily be attributed to the correct booking. Dojo provides the dojoPartyId for reference which the POS may use in place of generating a new internal ID, however, as we cannot guarantee uniqueness to the existing set on the POS then this is not recommended.
This step is also applicable if there is a walk in seated, the only difference is the exclusion of the reservationId in this scenario.
Step 4: (Optional) Party is updated using Dojo Bookings
PUT REST /v1/parties/{partyId}
If an update to the party is made, this allows Dojo to update the POS with additional party information, for example, this could be the party's allergen requirements in the form of guestRequests, a change in booking time, a new expected end-time or a new tableId has been assigned to the party.
Step 5: (Optional) Reservation is cancelled
DELETE REST /v1/reservations/{reservationId}
In the event a guest cancels their reservations, Dojo Bookings will issue a DELETE, to /v1/reservations/{reservationId}. If there is a party already associated, we will also issue a DELETE to /v1/parties/{partyId}
This flow diagram demonstrates how Dojo Bookings will interact with the POS system for seating guests when the action of seating them is performed on the POS software.
Step 1: Reservation is made ahead of time
A reservation is made ahead of time by the customer using Dojo Bookings platform. This reservation will be sent to the POS up to 24 hours ahead of time or on the day the reservation has been made for, containing information such as reservationId, startTime and tableId.
A reservation can also be created on the POS, in this instance a POS Event should be submitted using eventType:ReservationUpdated. Dojo Bookings will then call a GET reservationById where a new booking will be generated for any unknown reservation IDs.
Step 2: (Optional) There is an update to the reservation, made on the POS
This is a call made by the POS to the Dojo API
POST REST /epos/events
If the update to the reservation is recorded on the POS, then a POS Event should be submitted using eventType:ReservationUpdated, these events are notifications about changes relating to entities which are owned by the POS system and allow Dojo products to be able to react in near real time.
This request must include the reservationId.
Step 3: Dojo Bookings reacts to the event and confirms the updated details with the POS.
GET REST /v1/reservations/{reservationId}
Dojo will call the POS to confirm the updated reservation details using the reservationId, the response should include any and all up to date information on the reservation.
Step 4: The reservation is seated on the POS
This is a POS to Dojo API call
POST REST /epos/events
When the reservation is seated and recorded on the POS, then a POS Event should be submitted using eventType:partyUpdated, these events are notifications about changes relating to entities which are owned by the POS system and allow Dojo products to be able to react in near real time.
This request must includes a partyId which is designated by the POS and must correspond to the POS internal ID of the reservation that it corresponds to. This field must not be changed after creation.
Step 5: Dojo Bookings reacts to the event and confirms the Party details with the POS.
GET REST /v1/parties/{partyId}
Dojo will call the POS to confirm the updated party details using the partyId, the response should include any and all up to date information on the party.
The response from the GET Party by Id call will include details such as tableId, status, startTime and any hostNotes related to the party. If the party has ended, the endTime field should be set and stored for Dojo products to retrieve.
Step 6: (Optional) Party details have been updated on the POS
This is a POS to Dojo API call
POST REST /epos/events
In the event where a party has been updated, for example, moved tables in the venue then a POS Event should be submitted using eventType:partyUpdated
Step 7: Dojo Bookings reacts to the event and confirms the Party details with the POS.
GET REST /v1/parties/{partyId}
Dojo will call the POS to confirm the updated party details using the partyId, the response should include any and all up to date information on the party. This will then be relayed to RMS and the details updated.
The response from the GET Party by Id call will include details such as status, startTime and any new tableIds related to the party. In case of the update being the party has finished, the endTime should be updated and stored so that Dojo Bookings can obtain the endTime of the visit.
Step 8: The order details are updated on the POS
This is a POS to Dojo API call
POST REST /epos/events
In the event where an order has been updated, for example, it has been paid or items have been added to the table. A POS Event should be submitted using eventType:orderUpdated. This will provide the orderId assigned by the POS to Dojo Bookings
Step 9: Dojo Bookings reacts to the event and confirms the Order details with the POS.
Dojo will call the POS to confirm the updated Order details using the orderId, the response should include any and all up to date information on the order.
In the getOrderbyId response, there should be a partyId in the details.dineIn object, this allows Dojo Bookings to attribute the order to the correct party.
Step 10: (Optional) Reservation is deleted on the POS
POST REST /epos/events
If at anytime a user needs to delete a reservation using the POS then a POS Event should be submitted using eventType:ReservationUpdated after the booking has been deleted. Dojo Bookings will then call getReservationById where the POS should return a status code 404: Not found. Dojo Bookings will then delete the reservation from its records as it no longer exists.