Skip to content


Definition of the Structure

All the attributes are embedded in the following tags:

<?xml version="1.0" encoding="ISO-8859-1" ?>

The XML-structure is marked at the end with the ASCII character EOT (hex 04). Therefore, the software engineers have a simple and powerful possibility to scan the end of the XML–structure. The EOT is added to all records from both sides. See FAQ Why does the interface not receive the data sent?.

Updates and continuous integration

This interface ensures backwards compatibility in general. Existing fields will not be changed or removed. Under very rare and special circumstances when such changes will be performed, we will state such a change in particular through this interface specification. New requests, fields and blocks can be added at any time. Each third party interface, which connects to this interface, needs to ensure that such enhancements do not affect the function of the interface in a negative way.


The Date, Time and Date Time-attributes are coded according to the IS08601 definition of the ISO-Committee


The international standard date notation is: YYYY-MM-DD

where YYYY is the year in the usual Gregorian calendar, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31.

For example, the fourth day of February in the year 1995 is written in the standard notation as 1995-02-04


The international standard notation for the time of day is: hh:mm:ss

where hh is the number of complete hours that have passed since midnight (00-24), mm is the number of complete minutes that have passed since the start of the hour (00-59), and ss is the number of complete seconds since the start of the minute (00-60). If the hour value is 24, the minute and second values must be zero. [The value 60 for ss might sometimes be needed during an inserted leap second in an atomic time scale like Coordinated Universal Time (UTC). A single leap second 23:59:60 is inserted into the UTC time scale every few years as announced by the International Earth Rotation Service in Paris to keep UTC from wandering away more than 0.9 s from the less constant astronomical time scale UT1 that is defined by the actual rotation of the earth.]

An example time is: 23:59:59

which represents the time one second before midnight.

Combined Date/Time Formats

The symbol T is used to separate the date and time parts of the combined representation. The complete representation is as follows: 1993-02-14T13:10:30

The date and/or time components independently obey the rules already given in the sections above, with the restrictions:

  • The date format should not be truncated on the right (i.e., represented with lower precision) and the time format should not be truncated on the left (i.e., no leading hyphens).
  • When the date format is truncated on the left, the leading hyphens may be omitted.

ISO 3166

Normally, a hotel should be configured with the 2 character ISO 3166 country codes. Nevertheless, we offer the possibility to send and receive also the 3 character codes.

Definition of XML-Attributes

For all interfaces, which are provided by in XML notation, there is a minimum set of given attributes allowed in all operations, if nothing different is indicated.

These attributes are generally accepted and can occur during all operations (OC).

Attribute Denotation Type
RN Room Number, see What is the difference between RN and PH? String
ORN Old Room Number, if room move String
ARR Arrival Date Time
DEP Departure Date Time
LN Language of the Guest (ISO-Code 639-1, 2 characters) String
SALUTATION Salutation of the Guest String
TITLE Title of the Guest String
VIP VIP String
RNO Reservation Number uns. Long
RSNO Reservation Sub number uns. Int
SN Surname / Last name of the guest String
SN2 Second surname / last name of the guest String
PCIID Pre Check-In ID. This is a unique ID of the stay of the client in the hotel. uns. Long
GID Unique id of this guest uns. Long
CN Christian Name / First Name of the guest String
TG Type of guest of the clients, defined in the SIHOT-Installation , e.g.
1A = Adult
2A = Toddler…
AN Account Number Uns. Long
ORG Origin. This is the identifier of the SIHOT workstation or the workstation of the other system that executed this operation. String
TN Transaction number. This is a sequential number to identify univocally a data record sent between the two parts. This tag is mandatory for all records.
See FAQ Who keeps track of the Transaction Number TN?.
Uns. Long
SRC The SRC-Attribute indicates where this operation is coming from. String
PASSWD Guest-Password String
PAY-TV Pay-TV-permission char
PH Phone number to be charged or phone number where the wakeup request / room status was entered, see FAQ What is the difference between RN and PH?. uns. Long
PH0 – PH4 Phone numbers of the Room
Notes: 5 digits, right justified, leading 0
With suites, PH can get beyond PH4
uns. Long
AP Definition of the access points. The access point are defined in a key card system String
CS Coding Station String
NC Number of cards uns. Byte
CA Card action String
PPU Price per unit (including taxes, vat, …) in hotel currency BCD
UN Units Long
AMOUNT Total amount = PPU * UN BCD
HN Number of the hotel – each hotel has a <HN> uns. Long
MC Market code (type) of the guest. Please keep into account that in SIHOT a guest can have different market codes during the stay. In the IF always the market code of the arrival date of the guest is transferred. String
SF Share flag. Char
GTD Type of the guest String
GNR Number of the guest String
GMD Number of the hotel where the guest data is stored String
GDB Debtor number of the guest String
HQGID Central ID of the guest String
CREQ Credit request of the guest String
CREQSTATE State of the credit request of the guest String
ROOMSIMPLIED Adds a list of rooms that are implied in a suite if a record is sent for a suite and not for a single room String
BEDSIMPLIED Adds a list of beds that are implied in a room if there are beds defined in a room String
BED Contains the data of a bed in a room, currently consisting of <BEDNO> and <BEDKCID>
BEDNO Bed number String
BEDKCID Using the keycard ID of the bed instead of the bed number, if available. String
OBED Old bed number if room move String
ENTIREROOM The flag indicates if the checkout (CO) should be done only for certain person in the CO operation or the whole room.
CARD Contains the data of a card from a guest.
NR_FOR_THIS The number of the bed, room or suite that triggered this record. An external system can rely on this number e.g. to create a keycard so that it does not need to find out if the room number or the bed number should be used. String
KCID_FOR_THIS The key card ID associated to the NR_FOR_THIS String

Extensions specific to one interface can be indicated at any time in the interface directly.

Note: There are additional OCs and tags that are only for internal use, see FAQ How do I handle unknown tags or records?.

PCIID (Pre Check In ID)

The PCIID is a unique ID that identifies a guest during one stay in a hotel. It is already available when the reservation is made and so it can be used in the forecast. The important thing is that it remains the same during the complete stay of the guest so if the guest moves or checks out or even if his name is changed to a completely different guest with a different GID, the PCIID will not change. When the same guest returns, he will have a different PCIID for his next stay. To be more precise, it does not directly identify a guest but an entry in the list of persons assigned to a reservation.

To clarify this, here an example: When you enter a reservation in SIHOT, there is created an entry in the list of persons for each person that is part of this reservation.

E.g. 3 PAX from 01/03/2005 to 05/03/2005. So this reservation contains a list of 3 PAX:

  • Person A with PCIID 4711
  • Person B with PCIID 4712
  • Person C with PCIID 4713

You can assign names to these persons at any time before or after the check in. E.g. when the reservation is made, just one name is known, so PCIID 4711 is assigned the name “Smith” with GID 37623. This results in a GC with GID 37623 and PCIID 4711.

At check in, you change the name of the guest from “Smith” to “Black” with GID 92866 so you get a GC with GID 92866 and PCIID 4711. So this just means that the name of the person was changed, not that the person itself moved from one room to another or was checked out. You will also receive a CI for the PCIID 4711 with the GID 92866 and the room number. If the guest moves to another room, e.g. 302, you will receive a RM from 101 to 302 with the PCIID 4711 and at the checkout you will receive a CO with the same PCIID.

So to keep track of a guest, it is in general better to use the PCIID since this remains the same all the time while the GID might change.

Note: If the guest “Black” with the GID 92866 comes again from 06/03/2005 to 07/03/2005, he will get a different PCIID but if he prolongs his stay to the 07/03/2005, he will keep the PCIID 4711 until he checks out.


Unknown attributes (tags) or records with unknown OCs have to be ignored by the interface! This means that these records are not evaluated but acknowledged with a return code of “99”. If configured properly, the interface will only receive records with OCs that are evaluated by this interface. The tag <HN> is only needed in an environment with several properties. It is used to assign identical room numbers to the correct hotel. If the tag <HN> is not sent, the currently active environment (defined in the database of SIHOT) is used.

Directions of OCs

OC Description From To
TS Time Sync SIHOT Interface
LA Link Alive SIHOT Interface
LA Link Alive Interface SIHOT
CO Check Out SIHOT Interface
CO Check Out Interface SIHOT
PCO Pre Check Out SIHOT Interface
RM Room Move SIHOT Interface
ACK Acknowledge SIHOT Interface
ACK Acknowledge Interface SIHOT
PS Posting simple Interface SIHOT
PE Posting extended Interface SIHOT
PP Posting payment Interface SIHOT
COS Class of Service SIHOT Interface
GI Guest Information SIHOT Interface
GC Guest Change SIHOT Interface
SM Send Message Interface SIHOT
WU Wake Up Message SIHOT Interface
WU Wake Up Message Interface SIHOT
WA Wake Up Answer Interface SIHOT
RST Room Status Interface SIHOT
DR Document reader Interface SIHOT
RS Restart Interface SIHOT
PAR Payment request SIHOT Interface
PAA Payment answer Interface SIHOT
EXMSG Extended message SIHOT Interface
MS Message status Interface SIHOT
RO Room occupancy SIHOT Interface
TR Transaction Interface SIHOT
RF Request Forecast Interface SIHOT
RR Room Request Interface SIHOT
FC Forecast SIHOT Interface
CR Change reservation SIHOT Interface
FSOA Request of a Statement of Account Interface SIHOT
SOA Statement of Account SIHOT Interface
PRECHECKIN Pre Check In SIHOT Interface
KEYDETAIL Details of the key Interface SIHOT
AC Assign / delete card SIHOT Interface

Error Handling (ACK)

All exchanged operations (OC) return a feedback to the sender. See Acknowledge.

Important Hint

The external system needs to wait until it receives the <ACK> or until the socket is disconnected. Should the socket be disconnected, the external system can assume a crash of the interface and handle this as an <ACK> with an error code.

If the external system nonetheless needs to use a timeout how long it waits for the <ACK>, this timeout should at least be one minute. Our system is a server where many processes interact and not a real time server just for this interface. Normally, the <ACK> will be sent within a second but it might even take longer than a minute depending on system load and database access by other services or users.

Should the external system deny a service since its timeout ended before the <ACK> on the posting record was received, it still needs to process the <ACK> when it comes later.

E.g. if a Pay-TV system sends a posting and its timeout ended before it receives the <ACK>, it may decide not to show the movie. If it receives the <ACK> later and the RC is 0, this means that the posting was done correctly in SIHOT.PMS. Since the movie was not shown, the Pay-TV system should send a cancellation of the posting immediately. Alternatively, it needs at least to show and log this problem.

Night Audit

There are no messages to send a “start of night audit” and “end of night audit”, because SIHOT can process postings also during the night audit.