# Dojo Bookings Documentation > Guides for integrating Dojo Bookings / RMS with POS reservations, parties, tables, areas, and order synchronization flows. API quick reference: - **API base URL**: https://api.dojo.tech - **Environment selection**: Sandbox and production both use `https://api.dojo.tech`; the API key determines which environment receives the request - **Authentication**: `Authorization: Basic ` (literal `Basic ` prefix; do not base64-encode `api_key:`) - **Version header**: `version: 2026-02-27` Bookings is bidirectional: Dojo Bookings and the POS keep reservations, parties, orders, tables, and areas in sync, while the POS remains the source of truth for its own data. Machine-readable specs: - [Dojo API v3](https://docs.dojo.tech/api/v3/bundled.json) - [EPOS Data API (REST)](https://docs.dojo.tech/epos-data/bundled.json) - [EPOS Data API (AsyncAPI)](https://docs.dojo.tech/epos-data-asyncapi/bundled.yaml) For complete Bookings integration, also load: - `llms-core-concepts.txt` — shared entity definitions and event vocabulary for reservations, parties, tables, areas, and orders - `llms-epos.txt` — capability registration and EPOS contract details This file contains all documentation content in a single document following the llmstxt.org standard. ## Introduction # 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](https://docs.dojo.tech/api-hosting/epos-data) 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](https://docs.dojo.tech/core-concepts/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. See [Registering capabilities](https://docs.dojo.tech/api-hosting/epos-data#registering-capabilities) for how each capability is registered with Dojo. **Registering a capability:** the heading for each capability below (for example `SearchOrders`, `GetOrderById`, `CreateOrderLock`, `RecordOrderPaymentById`) is the exact `name` value to send in the body of `PUT /epos/integrations/rest` or `PUT /epos/integrations/ws`. The version is sent alongside as a separate field (`"version": "v1"`); appending `V1` to the heading gives you the wire-level method Dojo invokes after registration (for example `RecordOrderPaymentByIdV1`). See [Registering capabilities](https://docs.dojo.tech/api-hosting/epos-data#registering-capabilities) for the full body schema. For backwards compatibility, registration also accepts the four legacy names `GetOrderBill`, `RecordOrderPayment`, `UpdatePartyById`, and `UpdateReservationById` — they are equivalent to `GetOrderBillById`, `RecordOrderPaymentById`, `UpdateParty`, and `UpdateReservation` respectively. New integrations should prefer the wire-aligned form shown in the headings below. The below capabilites are needed to support all aspects of the **Dojo Bookings** integration: ## Reservations ### CreateReservation > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations > See OpenAPI spec for CreateReservationV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-CreateReservationV1_Request 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. ### UpdateReservation > See OpenAPI spec for PUT endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-put-reservations-reservationId > See OpenAPI spec for UpdateReservationV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-UpdateReservationV1_Request 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 > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-get-reservations-reservationId > See OpenAPI spec for GetReservationByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-GetReservationByIdV1_Request 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-search-reservations > See OpenAPI spec for SearchReservationsV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-SearchReservationsV1_Request This capability allows Dojo to retrieve **reservations** from a POS and can include filters such as table Id and time slot. ### DeleteReservationById > See OpenAPI spec for DELETE endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-delete-reservations-reservationId > See OpenAPI spec for DeleteReservationByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-DeleteReservationByIdV1_Request This capability allows Dojos to delete a specific **reservation** by using the reservation Id. ## Parties ### CreateParty > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties > See OpenAPI spec for CreatePartyV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-CreatePartyV1_Request 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. ### UpdateParty > See OpenAPI spec for PUT endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties/operation/v1-put-parties-partyId > See OpenAPI spec for UpdatePartyV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-UpdatePartyV1_Request 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 > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties/operation/v1-get-parties-partyId > See OpenAPI spec for GetPartyByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-GetPartyByIdV1_Request 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties/operation/v1-search-parties > See OpenAPI spec for SearchPartiesV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-SearchPartiesV1_Request 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 > See OpenAPI spec for DELETE endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties/operation/v1-delete-parties-partyId > See OpenAPI spec for DeletePartyByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-DeletePartyByIdV1_Request This capability allows Dojos Epos Data API to delete a specific **party** by using the party Id. ## Orders ### GetOrderById > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Orders/operation/v1-get-orders-orderId > See OpenAPI spec for GetOrderByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-GetOrderByIdV1_Request This capability enables Dojo to retrieve detailed information about a specific order using its unique order ID. This is crucial for order tracking and status updates. ### SearchOrders > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Orders/paths/~1v1~1orders~1search/post > See OpenAPI spec for SearchOrdersV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-SearchOrdersV1_Request 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Tables/operation/v1-search-tables > See OpenAPI spec for SearchTablesV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-SearchTablesV1_Request This capability enables searching for Tables from the POS system. ## Areas ### ListAreas > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Areas/operation/v1-list-areas > See OpenAPI spec for ListAreasV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-receive-ListAreasV1_Request 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. --- ## Flows > This section covers the step-by-step flows to integrate with Dojo Bookings > **Info:** 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. 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 ![Payment Intent Flow](https://docs.dojo.tech/images/rms-to-pos-flow.png) **Flow diagram: Rms To Pos Flow** ```mermaid sequenceDiagram participant RMS participant B as DOJO Backend participant EPOS Note over RMS: Reservation is made ahead of time RMS->>B: Reservation is generated B->>EPOS: CreateReservation (POST v1/reservations) EPOS-->>B: 200 OK + {responseBody} Note over RMS: Reservation is amended RMS->>B: Reservation is amended B->>EPOS: UpdateReservation (PUT /v1/reservations/{id}) EPOS-->>B: 200 OK + {responseBody} Note over RMS: Reservation is seated RMS->>B: Reservation is given a party ID B->>EPOS: CreateParty (PUT /v1/parties) EPOS-->>B: 200 OK + {responseBody} Note over RMS: Party is amended using RMS RMS->>B: Updated details are provided B->>EPOS: UpdateParty (POST /v1/parties) EPOS-->>B: 200 OK + {responseBody} ``` ### Step 1: Reservation is made ahead of time > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties > See OpenAPI spec for CreateReservationV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-CreatePartyV1_Request 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 > See OpenAPI spec for PUT endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties > See OpenAPI spec for UpdateReservationV1 endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-put-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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties > See OpenAPI spec for CreatePartyV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-CreatePartyV1_Request 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 > See OpenAPI spec for PUT endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties > See OpenAPI spec for UpdatePartyV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-UpdatePartyV1_Request 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 > See OpenAPI spec for DELETE endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-delete-reservations-reservationId > See OpenAPI spec for DeleteReservationByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-DeleteReservationByIdV1_Request 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**. ![Payment Intent Flow](https://docs.dojo.tech/images/pos-to-rms-flow.png) **Flow diagram: Pos To Rms Flow** ```mermaid sequenceDiagram participant RMS participant B as DOJO Backend participant POS Note over RMS: Reservation is made ahead of time RMS->>B: Reservation created B->>POS: CreateReservation (POST v1/reservations) POS-->>B: 200 OK + {responseBody} Note over POS: Reservation is amended POS->>B: UpdateReservation Event (POST REST /epos/events) B->>POS: GetReservationById (GET /v1/reservations/{id}) POS-->>B: UpdateReservation (200 OK + response) B-->>RMS: Reservation updated on the RMS Note over POS: Reservation is seated on the POS POS->>B: UpdateParty Event (POST /epos/events) B->>POS: GetPartyById (GET v1/parties/{id}) POS-->>B: 200 OK + response B->>RMS: RMS updated with PartyId & info Note over POS: Party is updated (e.g. Moved table) POS->>B: UpdateParty Event B->>POS: GetPartyById POS-->>B: 200 OK + response B->>RMS: RMS updated with PartyId & info Note over POS: Order is updated (e.g. Items added) POS->>B: UpdateOrder Event B->>POS: GetOrderById (GET v1/orders/{id}) POS-->>B: 200 OK + response ``` ## ### Step 1: Reservation is made ahead of time > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/epos-data/api#tag/Parties > See OpenAPI spec for CreateReservationV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-CreatePartyV1_Request 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](https://docs.dojo.tech/core-concepts/pos-events) 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/api#tag/Events/paths/~1epos~1events/post If the update to the reservation is recorded on the POS, then a [POS Event](https://docs.dojo.tech/core-concepts/dojo-events) 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. > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-post-reservations > See OpenAPI spec for GetReservationV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-GetReservationByIdV1_Request 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/api#tag/Events/paths/~1epos~1events/post When the reservation is seated and recorded on the POS, then a [POS Event](https://docs.dojo.tech/core-concepts/dojo-events) 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. > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-get-reservations-reservationId > See OpenAPI spec for GetPartyByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-GetPartyByIdV1_Request 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](https://docs.dojo.tech/epos-data/api#tag/Parties/operation/v1-get-parties-partyId) 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/api#tag/Events/paths/~1epos~1events/post 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. > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Reservations/operation/v1-get-reservations-reservationId > See OpenAPI spec for GetPartyByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-GetPartyByIdV1_Request 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](https://docs.dojo.tech/epos-data/api#tag/Parties/operation/v1-get-parties-partyId) 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/api#tag/Events/paths/~1epos~1events/post 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. > See OpenAPI spec for GET endpoint details: https://docs.dojo.tech/epos-data/api#tag/Orders/operation/v1-get-orders-orderId > See OpenAPI spec for GetOrderByIdV1 endpoint details: https://docs.dojo.tech/epos-data/ws/api#spec-operation-send-GetOrderByIdV1_Request 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 > See OpenAPI spec for POST endpoint details: https://docs.dojo.tech/api#tag/Events/paths/~1epos~1events/post If at anytime a user needs to delete a reservation using the POS then a [POS Event](https://docs.dojo.tech/core-concepts/pos-events) 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.