SIHOT.RMS SOAP interface

The SIHOT.RMS SOAP interface is the further development of the SIHOT POS interface from an Ascii-based interface to an XML-based one.

The Transport Protocol

SIHOT.RMS webservices are SOAP services that are published via HTTPS. Depending on the use case and version there are more or less service endpoints available. On this documentation all publicly available services for the current SIHOT version are documented. Example requests are provided on each message page. A complete WSDL file is available at https://partner-api.sihot.com/PDOCS/API/RMS/?wsdl.

Security

To consume a webservice an access token (securityID) is required within the message communication. This SecurityID is generated via an AuthenticationRequest. Check also Authentication for more details. A positive response will be communicated with a HTTP 200, and the body of the message gives the response detail. There are a range of negative responses, depending on the operation being performed. Successful responses may contain a payload which is formatted depending of the interface specification. The structure of the body depends on the type of request.

URL Conventions

Even while the URLS for different locations may vary the below standard principals should apply. https://{DNS of service}/{customerid}/API/{protocol}/

This translates in example for a message of the SIHOT.PMS-RMS-Interface to: https://api.sihot.com/X4711/API/RMS/

Common Configuration

  • Ordinal numbers for the configured way of transfer (depending on the configuration: supercat, middlecat, articlecat or articleno) have to be in the range from 1 to 100.
  • In case that the shift function is used, the range for supercat, middlecat, articlecat or articleno will be 1 to 25.
  • Shift numbers have to be in the range from 1 to 4, if used.
  • Cash register numbers/outlets have to be in the range from 1 to 30. We support 5 different vat rates.
  • The services are unique via the combination of VAT (VAT code), Cat ID and cash register number
  • A mapping of the services can be created on the part of the cash register company. The service numbers must then be sent in the ServiceID tag.
  • In a multi property environment, the mandator can be sent in the requests to find the correct account. In a standard installation, this tag should not be used since the interface will automatically search for the guest in the correct mandator.