Skip to content

Booking API: How to use

For easy test of the Booking API. Some of the requests require a logged in user. For exemple “get_all”. Booking API Swagger

“System” Level (highest level today)
System: The highest level in the booking hierarchy, representing a company. A single System can contain one or more Units.

  1. “Unit” Level
    Unit: Equivalent to a restaurant or cost center. Units can be further divided into Sections to specify physical areas or activity types.
  2. “Section” Level
    Section: Defines specific areas within a Unit and associates them with activities. Resource Allocation: Sections are assigned to physical resources in the Table Map, allowing for organized grouping. For example:
    • In a restaurant, Sections might include Table Reservation areas.
      1. Tables in the dining area may be linked to a section called Table Reservation Inside, while outdoor tables are linked to Table Reservation Outside.
    • In an activity center, Sections could encompass different activities like Table Reservation, Bowling, or Shuffleboard.
  3. “Rule” Level
    Rules: Each Section can have one or more Rules (also referred to as rule Id and web rules and ) with Rule Id’s to control booking conditions, such as:
    • Date and Times available for booking
    • Guest Limits per booking session, and much more
      In a section called Table Reservation, Rules could specify different booking categories such as Lunch, Dinner, and Sunday Brunch.
    1. Rule Status: Default status is Ongoing. Rules follow a weekly schedule and repeat every week unless a specific date adjustment is required.
    2. Status Options: Rules can have different statuses to indicate their current application:
      Ongoing: Active on a repeating basis
      Changed: Modified for specific dates or times
      Addition: New rule added temporarily or permanently
      Closed: Rule is inactive or no longer available\
  4. “Day state”
    1. Depending on the Rules a given day holds a so-called Day state. Possible status is Undefined = 0, Closed = 1, Open = 3
  5. Rule Periods
    1. Rules are connected to Rule Periods for easy future adjustments.\

Understanding Availability and Rule IDs

Section titled “Understanding Availability and Rule IDs”
  1. Availability via Rule IDs

Each day may contain one or more Rule IDs, each specifying:

  • Name: Title for the booking rule
  • Comments: Information for guest guidance
  • First and Last Bookable Times: Time slots available for booking
  • Step Length: Time interval (in minutes) between available booking times
  • Waitlist Status: Indicates if a waitlist is available
  • Recoup Time: Hidden time blocks not shown to guests
  • Restrictions, which include:
    • Maximum number of guests or bookings per slot
    • Available until” (how close to booking time reservations are allowed)
    • Group size limits\
  1. Additional Configurations on Rules
    • Filter Tags: For filtering specific rules in responses
    • Markings: Pre-set tags displayed on end-user views for added information
    • Menu Template: If linked to a specific Rule ID
    • Payment Options:
      • No-show Prevention: Requires card registration
      • Pre-payment Options:
        • Menu item-level charges
        • Per guest or per booking charges
        • Total booking charges based on resources needed for group size
        • Combination “Per guest and Menu item”, Per booking and Menu items
  2. Booking Creation Process
    Steps:
    1. Step 1: Check availability (for one or multiple systems and units)
    2. Step 2: Create a pending booking
    3. Step 3: Finalize the pending booking
  3. Steps for creating a Booking
    1. Step 1: Retrieve available times, organized in “webRules” (includes names and comments for user guidance), and display these times to the end user. Ask for a so-called system name, unit (Unit Id) and if needed also for section (Section Id).
      API Endpoint: https://rms.caspeco.se/api/booking/v1/WebBooking/AvailableTimes or https://rms.caspeco.se/api/booking/v1/WebBooking/AvailableTimes/BulkFetch for list of systems.
    2. Step 2: When the user selects a start time, create the booking by posting the chosen Rule ID, date, and time. The system will set the booking duration per rule, resulting in a booking with a “Pending” status.
      API Endpoint: https://rms.caspeco.se/api/booking/v1/WebBooking/WebBookings
  4. Adding Pre-Order Items (If Applicable)
    If supported by the Rule ID, use the menuGuid and bookingGuid to retrieve the menu template. Allow the guest to select items and quantities, then post these selections.
    Menu Endpoints:
  5. Step 3: Finalize the Booking:
  6. Booking Expiration and Updates
    • Expiration: Pending bookings expire after 5 minutes if not updated, freeing up resources. To prevent expiration, update the booking promptly. API Endpoint: https://rms.caspeco.se/api/booking/v1/WebBooking/WebBookings/{id}/Refresh
    • Restrictions on Updates: Pending bookings cannot be modified with additional resources. If more resources are needed, cancel the booking and begin selection again.
  7. Cancellation Options

How to Fetch Bookings through the Caspeco Booking API

  1. Access Requirements
    • User Creation: To access booking data through the Caspeco Booking API, a User must first be created for you within Caspeco’s system.
    • PAT Creation: With these User credentials, you can generate a Personal Access Token (PAT), which will be used to fetch data. See Create PAT.
    • System Connections: This User can be linked by Caspeco to one or multiple “systems” (companies).
  2. Authorization
    • Data Controller Approval: For access to specific systems, Caspeco requires written approval from the company’s Data Controller to validate the request and ensure compliance.
  3. Fetching Booking Data
    • Endpoint for Booking Data: Use the “List web bookings” endpoint to retrieve booking data:
      Endpoint: https://rms.caspeco.se/api/booking/v1/WebBooking/Webbookings_getall
    • Requirements for Data Fetching: Your PAT must be valid, and the User must be authorized in the specific system from which you are fetching data.
    • System and Unit Selection: If a system includes multiple units, the API allows you to request booking data for one or several units by using the system name in your call.
  4. Filtering and Time Parameters
    • Start and End Time: When filtering data by startTime and endTime, these refer to the actual date and time of the booking itself.
    • Created Date: Included in the data is createdDate, indicating when the booking was originally made.
    • Regular Data Fetching: If you need to fetch booking data regularly, it is strongly recommended to use the changedFrom parameter to retrieve only updated or newly created bookings.