--- created: 2022-05-01T00:00 updated: 2024-07-10T11:11 author: ibelsa API team title: Guide for kiosk applications --- # Guide for kiosk applications All of the endpoints listed here and others can be found in our online documentation: [Documentation](/api/doc) This document is intended as a suggestion. Sometimes it can be useful to use endpoints other than those listed here. This documentation should always be used in conjunction with theonline documentationfor the ibelsa API. ## A. Walkin It is possible to create new bookings. ### 1. Rate **GET /api/get/allactiverates** [Get Active Rates](/api/doc#get--api-get-allactiverates) The end point supplies all rates that can be used for a booking. ### 2. Availabilities **GET /api/get/availabilities/{start}/{end}/{rate_id}/{person_count}** [Get Availabilities](/api/doc#get--api-get-availabilities-{start}-{end}-{rate_id}-{person_count}) This endpoint provides the availability for the defined period and rate for all room categories.\ The "person_count" parameter specifies the minimum occupancy. This value has an influence on the selection of the room category.\ Important:The output takes place on a daily basis. If a booking is to be made in the period, it must be checked for each booking day whether the availability is greater than zero. ### 3. Create a reservation **POST /api/set/create/reservation** [Create Reservation](/api/doc#post--api-set-create-reservation) Important:This endpoint does not check whether theavailability for the booked days is greater than zero. Overbooking is therefore possible. ### 4. Add room to a reservation **POST /api/set/add/room_to_reservation** [Add room to reservation](/api/doc#post--api-set-add-room_to_reservation) Endpoint C3 only allows one room to be created.\ This endpoint allows adding a room reservation to an existing main reservation. ## B. Retrieve existing bookings ### 1. Get bookings in a time period **GET /api/get/timespan/{entity}/{start}/{end}/{last_modified}** [Get in timespan](/api/doc#get--api-get-timespan-{entity}-{start}-{end}-{last_modified}) **{entity} = reservations** Returns a list of all room reservations that fully or partially fall within the specified period. **{last_modified}** Reduces the result list to bookings that were created or changed on this date or later. This is particularly useful if the data is to be saved in your own system and updated regularly. Important fields from the data: **id**\ the internal ID of the room reservation **status**\ Possible values are: BOOKED, CHECKED_IN, CHECKED_OUT, NO_SHOW, NO_SHOW_GUARANTEED **self_pay**\ Possible values are: NO, ADDITIONAL, ALL\ **NO** : the recipient of the whole invoice of the reservationis the “invoice recipient” of the booking.\ **ALL** : the recipient of the whole invoice of the reservationis the main guest.\ **ADDITIONAL** : two invoices are issued. The invoice itemsof the room rate go to the “invoice recipient”. Any additional services go to the main guest. **invoice_items**\ a list of all invoice items for the reservation. **main_reservation**\ Here you will find, among other things, the details of the invoice recipient ### 2. Get booking by ID **GET /api/get/single_id/{entity}/{id}** [Get Single Entity by ID](/api/doc#get--api-get-single_id-{entity}-{id}) **a)** **{entity} = roomreservations**\ Returns a single reservation according to its internal ID. The structure of the output is the same as in point 1. **{id}**\ The internal ID of the room reservation. **b)** **{entity} = mainreservations**\ Delivers the main reservation with all the room reservations it contains. **{id}**\ The internal ID of the main reservation ### 3. Get single entity by determined number **GET /api/get/single_number/{entity}/{number}** [Get Single Entity by Number](/api/doc#get--api-get-single_number-{entity}-{number}) **{entity} = mainreservations**\ **{number} -> reservation number of the main reservation, visible in the application.** The main reservation is the superordinate construct that contains the room reservation or several room reservations. The reservation number is assigned to the main reservation. This means that a reservation with several rooms has only one reservation number. We are talking about a group reservation. See a diagram in the appendix that shows the relationships graphically. The structure of the output is the same as in point 2. ## C. Edit contacts ### 1. Update existing contact **POST /api/set/contactdata** [Set Contact Data](/api/doc#post--api-set-contactdata) This endpoint enables the data of an existing contact to be changed. The internal ID of the contact must be known. Due to current events (Corona), one contact field is described in more detail here:\ **smart_check -> yes / no**\ After the guest status regarding Corona has been checked, this flag can be set accordingly. **yes** means that the corona check was carried out successfully.This flag should only be set for guests with a reservation. This status is indicated in the reservation in ibelsa. This information is automatically deleted after the reservation is checked out. The **smart_check** field then has no value ### 2. Update the invoice recipient of a reservation **POST /api/set/roomreservation/invoicerecipient** [Set Roomres Invoice Recipient](/api/doc#post--api-set-roomreservation-invoicerecipient) This endpoint needs the internal ID of the room reservation. A room reservation is always assigned to exactly one main reservation. Because the invoice recipient is linked to the main reservation. ### 3. Handle additional guests of a reservation **POST /api/set/roomreservation/handle_additional_guest** [Handle additional Guests](/api/doc#post--api-set-roomreservation-handle_additional_guest) This endpointis notintended to change the data ofan existing contact. All additional guests can be manipulated. The main guest remains unaffected. Likewise, the number of guests for the room cannot be changed. Three actions are possible: **1. remove**\ The contact with the defined internal ID is removed as a guest of the reservation. **2. add**\ The contact details of the new guest must be transmitted. If the contact does not exist, it will be created. Otherwise the existing contact will be used as an additional guest. **3. replace**\ Works like "add", only that the guest is exchanged for another contact. ## D. Check in ### 1. Check in a reservation **GET /api/set/roomreservation/checkin/{entity_id}/{do_register_guest}** [Checkin](/api/doc#get--api-set-roomreservation-checkin-{entity_id}-{do_register_guest}) **{entity_id} -> internal ID of the room reservation** A reservation can be checked in with this endpoint. A clean room must already be assigned to the room. Otherwise it is not possible to check in. ### 2. Check in with room allocation **GET /api/set/roomreservation/allocate/checkin/{entity_id}/{do_register_guest}** [Checkin with Room allocation](/api/doc#get--api-set-roomreservation-allocate-checkin-{entity_id}-{do_register_guest}) **{entity_id} -> internal ID of the room reservation**\ Same function as in 1. If no room is assigned, a free, clean room is automatically assigned to the booking. ### 3. Allocate room to a reservation **GET /api/set/allocate_room/{entity_id}** [Room allocation](/api/doc#get--api-set-allocate_room-{entity_id}) The endpoint makes it possible to automatically assign a free, clean room to a reservation thatdoes not yet have a room. ## E. Upselling ### 1. All available products **GET /api/get/products/available** [All Available Products](/api/doc#get--api-get-products-available) This endpoint provides a list of products that can be booked via the ibelsa API. These products must be labeled accordingly in ibelsa so that they appear here. ### 2. All optional package products **GET /api/get/products/optional/{rate_id}** [Optional Available Products](/api/doc#get--api-get-products-optional-{rate_id}) **{rate_id} -> internal rate-id that is used in the booking** The end point delivers all optional products that are linked to this rate and can therefore be booked. ### 3. Add products to the reservation **POST /api/set/add/products** [Add Products to Reservation](/api/doc#post--api-set-add-products) With this endpoint, products can be booked for a reservation. To do this, the internal ID of the reservation must be known. The products can be obtained from the endpoints described above. ## F. Invoices See a diagram at the end that shows the relationships graphically. Before a reservation can be checked out, all open invoices must be closed. Some of the following endpoints require either an invoice ID or the invoice item ID. One way to do this is to take this information from the endpoints described above (B 2, B 3). #### Reservation based payments **INFO**\ **As many kiosk systems want to make payments on a room reservation basis so that they don't have to deal with invoices, we have set up new endpoints for this:**\ [Kiosk payment](/doc/api/kiosk_payment) ### 1. Payment methods and invoice templates **GET /api/get/hotel/payment** [Get Payment Methods](/api/doc#get--api-get-hotel-payment) This endpoint provides the ID and name of all payment methods and invoice templates. In consultation with the hotel, a decision must be made which will be used when closing invoices. The information of this end point is required in the following two end points (2, 3). ### 2. Close an invoice **GET /api/set/invoice/paid/{entity_id}/{template_id}/{payment_method_id}/{send_invoice}** [Close Invoice](/api/doc#get--api-set-invoice-paid-{entity_id}-{template_id}-{payment_method_id}-{send_invoice}) **{entity_id} -> internal id of the invoice**\ **{send_invoice} -> should ibelsa send the invoice document?** If the invoice recipient has an email address, ibelsa can send the invoice document there. ### 3. Pay part of the bill **POST /api/set/roomreservation/paidpartial** [Pay Parts of the Roomreservation](/api/doc#post--api-set-roomreservation-paidpartial) Via this end point, invoice items can be moved from one invoice to a new invoice and then automatically closed. ibelsa can send the invoicedocument to the invoice recipient on request.\ Of course, you can only move invoice items from open invoices. ### 4. Split invoice of a reservation **POST /api/set/roomreservation/splitinvoice** [Split Invoice of Roomreservation](/api/doc#post--api-set-roomreservation-splitinvoice) Via this end point, invoice items can be moved from one invoice to a new invoice.\ Both invoices remain open. ### 5. Update the invoice recipient of an invoice **POST /api/set/invoice/invoicerecipient** [Change Invoice Recipient of Invoice](/api/doc#post--api-set-invoice-invoicerecipient) The invoice recipient on the invoice is taken from the reservation. If necessary, the invoice recipient can be changed on the invoice without changing the data in the reservation.\ A change to the invoice recipient is only possible for invoices that have not yet been closed. ## G. Check out ### 1. Check out a reservation **GET /api/set/roomreservation/checkout/{entity_id}/{pre_checkout}** [Checkout](/api/doc#get--api-set-roomreservation-checkout-{entity_id}-{pre_checkout}) There are two requirements for a successful checkout. * The day of booking in ibelsa must coincide with the day of departure of the reservation (exception: pre_checkout=yes). * All invoices must be closed. * In the case of a group booking, you can also check out if the invoice is open. The last booking of a group reservation can only be checked out after all invoices have been closed. **{pre_checkout}**\ In the event of early departure, you can check out before the end of the reservation. The parameter _pre_checkout_ must have the value _yes._ The reservation in ibelsa is shortened to the check-out day. ## Pay-status of a booking If you want to check-in a reservation, you need to know whether the reservation has already been paid for or not. If this flag is activated you have a checkbox for every reservation. You have to mark the reservations manually. Using the endpoint “Get all entities in a timespan” (see in Documentation: [Get all Entities in Timespan](/api/doc#get--api-get-timespan-{entity}-{start}-{end})) you can obtain the value of this flag. E.g.https://rooms.ibelsa.com/api/get/timespan/reservations/{start_date}/{end_date} \ The section “**main_reservation**” contains the parameter **duty_of_payment_at_kiosk**.\ The value “**true**” means that the reservation must bepaid for.\ The value "**false**" means that the reservation has alreadybeen paid for. The flags in the application:\  In the sidebar:\  In the reservation mask:\ 

Author: Created: Updated:

This page was generated from a Markdown file.

Would you like to view the content in your favourite Markdown reader? Raw Markdown