Changelog

Version 1.1 Changes

The following changes were introduced to support payments and suburbs.

Added the payments field to bookings to allow a partner App to associate payments with a booking.
Added the suburb field inside the customer.address field for the customer’s suburb.
Added createdAt and updatedAt field to the bookings response payload.
Added the dateType filter which allows the searching of bookings on different date fields (previously only startTime).

Booking entity

New/updated Field	Description	Change	Change Description
payments	Optional list of payments associated with a booking.	New	Added to handle scenarios where the partner App wished to associate a payment with a booking. For example, if a partner App wanted to represent a deposit payment on a booking.
customer.address.suburb	Suburb of the customer	New	New field representing the customer’s suburb.

For Apps

Payments on a booking created/updated by the App will be sent to the POS.
Customer's suburb details on a booking created/updated by the App will be sent to the POS.

For POS systems

Bookings can contain an optional list of payments from the App
Customer's suburb details can also be received in bookings.

Release Notes (Version 1.0)

Introduces a new Asset concept that allows consumers to book different types of entities. As of now we support Room and Table assets. With more to come in future releases

Supports additional fields, more details in the documentation:

startTime - start time for the booking
endTime - end time for the booking
notes - notes specific to the booking.
bookingStatus - current status of the booking
customer - customer making the booking
asset - asset information of the booking

Deprecated fields:

status - status of the booking, in favor of bookingStatus which supports asset agnostic statuses.

For Apps

New bookings that are created in your booking system will be sent to the POS.
Update details of existing bookings.

For POS systems

Create walk-in from the POS, currently only supported for Table asset.
Update an existing Booking.
Retrieve & filter a list of bookings from the POS
Retrieve a list of changes that have been made to a booking

Release Notes (Version 0.1)

We have heard from our merchants that Booking and Reservation apps are valuable for supporting their business.

We have learned how much extra work it puts on the Merchants and their POS to accept these Apps. For Merchants, the effort to seat the reservation both into the Booking app and the POS (particularly during busy periods) can be quite onerous. For Apps, there is limited visibility into the status of that reservation in order to know when to open up the table for more customers.

The goal of Tyro Connect’s Booking API is to alleviate both of these problems by developing an API that has been specifically designed to support all types of Booking Apps. The key value proposition for POS Partners is that one integration with our Booking API unlocks different Booking Apps for Merchants and will share the status of the reservation back to Booking App Partners. For Merchants, to be able to seat a reservation from either their POS System or their Reservation App saves time and eliminates errors. Version 0.1 of the Booking API supports the following:

Seating a reservation in either the POS or the Booking App
Sharing table status based on events from the POS back to the Booking App