2. char pmslink HTTPCNX API FOR PBX

Posted28/07/2022

Updated08/09/2022

ByGari Iruretagoiena

22/07/2021.
Version for PBX based on general API.

Description

char pmslink is an intelligent middleware that allows the integration of different devices and hotel systems
(PBX, TV, Hotspot, multimedia, home automation, app guest access, minibar, etc.) with the property management
system (PMS).

www.charpmslink.com

This integration does not only transform links and protocols to connect every system. It goes further and adds
intelligence to those connections, controlling its status, apporting traceability, managing buffers, adapts the
default values of each single system, and uses a single PMS interface in order to integrate all the devices and
systems connected to it.

char pmslink adapts itself to any architecture, supports any kind of system such as cloud, remote, locals, monohotel, multi hotel, etc.

Normally equipment and systems are integrated with pmslink via their own API, which is implemented by char
and added to the library of integrated systems.

In cases where there is no appropriate API from the equipment / system to be integrated, or it does not provide
the required functionality, we offer the possibility of integration using one of pmslink’s standard APIs, which
cover different links, different flows of the information, different data format, and, in general, are versatile to
facilitate integration according to the design and architecture of the equipment to be integrated.

httpcnx is one of the standard pmslink APIs. In this case an API based on REST and JSON format.

httpcnx for PBX is an extract of the general API in which, in order to simplify the documentation, only the
methods and data that are commonly used in the management and integration of a PBX system in a hotel
environment are defined.

If necessary, it is possible to enhance the functionality offered by this API by adding methods and data covered
by the general API.

In the same way, the implementation of this API can be reduced to the minimum required.

Since the objective is to integrate and provide the functionality necessary for a PBX system to adapt to the needs
of a hotel, the methods and terms used refer to common hotel concepts: ‘checkin’, ‘guest data’,’ checkout’, etc.
In each case it is clarified what actions and configurations are involved for the PBX system in each of these
concepts.

This document describes:

The steps to be followed for the integration process.
The standard hotel functionality that a PBX system for a hotel is expected to provide.What functionality is related to each of the events and actions managed by pmslink.
The API details on connections, authentication, requirements, data structure and other details needed
for the implementation.

Development process, testing, certification and realease

This API is considered as public domain, but its use is restricted to char pmslink integrations and can’t be allowed
its use for direct integration with other systems.

char does not apply any economical charge to the system that creates the integration with char pmslink using
this API.

The basic steps in order to create the integration are the following ones:

The party interested to integrate with char pmslink should contact https://charpmslink.com/contact/ in order to start the process and obtain more extended information about the process itself and formalize a technical agreement (view template).

char and the system to be integrated will coordinate the features and functionality suitable for this integration, as well as those that are not offered directly but char pmslink can offer by its own means.
For example, wake-up functionality or code dialling via CTI, SIP, etc.
Once the functionality, endpoints and data involved have been defined, char will generate a specific
driver for the system to be integrated, which will be the basis for testing, final validation and use in
the hotels.
Throughout the development process, char will provide all the necessary support and assistance,
through expert@char.es and any voice contacts that may be agreed in advance.
Once the development of the system to be integrated has been completed, the activation of a test
environment will be coordinated by char, the first tests will be carried out jointly and the final
validation will be done.
Once validated, it will be considered as an integrated system for all intents and purposes, being released
to public, including it in the integrated systems list and notifying through the common news channels.
The integrated system will be able to publish and advertise at its will the integration and the additional
value that provides the integration itself.

Once the previous steps are done, char will have a fluid relationship with the integrated system to solve possible
issues with its installations, adjustments and updating its functionalities in the cases that is needed.

Data flow and basic functionalities

Basically, the functionality required for a PBX system to suit the needs of a hotel is related to the services offered
to the guest and the services required by the hotel staff to serve the guest.

It is understood that the actions and data are related to each of the extensions of the PBX system in a room. In
this context, rooms with several extensions will be managed by pmslink independently for each of them. For
example, if there is an extension (telephone) in the bedroom and in the bathroom, pmslink will handle them
independently.

The functionality offered by the PBX system is, or may be, related to:

The PMS system, through Integration with it.
Additional tools for specialised services, such as Housekeeping or minibar systems.
pmslink’s own tools that complement other integrated systems.

So, in the Integration, pmslink will connect transparently with the PMS system and/or other systems that might
be involved according to each type of action or information.

Features provided by the PBX system to the hotel through the integration:

It will depend on the features of the PBX system, being considered

RELEVANTS:

When receiving a call from an occupied room, show the name of the main guest on the reception display and other hotel services, so that the guest can be identified and attended to in a personalized manner.
Provide voice guidance and messages in the language of the guest occupying the room.
Prevent outside calls from extensions in unoccupied rooms.
Allow outside calls from extensions in occupied rooms, with the possibility of limiting their scope or even restricting them completely depending on the type of guest.
Make wake-up calls at the scheduled wake-up time. This functionality can be provided directly by the PBX System or through pmslink tools, using the resources available in the PBX that make it possible (CTI, SIP extensions, etc).

ADDITIONALS:

In the case that the hotel reception and other services have terminals with a suitable size display, when receiving a call from an occupied Room, show, in addition to the name of the main guest, information about their language, stay and VIP level.
Visual indicator, by a LED or any other indicator on the room’s telephone, about the existence of a ‘message waiting’ pending to be consulted to the reception or other hotel services.
Activate/deactivate the ‘Do Not Disturb’ feature, to deny incoming calls when the feature is activated.

Data provided by the PBX system to the hotel through the integration:

It will depend on the features of the PBX system, being considered

RELEVANTS:

Cleaning codes / Room status. Maids, through the room’s telephone, by dialling different codes for each type of status (clean, inspected, dirty, blocked, out of order, …) will communicate their status so that Housekeepers, Reception, or other hotel services can carry out the appropriate actions according to their state of cleanliness and availability.
Wake-up result communication: Completed (call answered), not completed (call not answered, extension busy, extension disconnected).
The sending of records of outgoing calls made by guest with basic data for calculating their cost (destination, duration) and sending this information to the PMS (billing calls / call accounting).

ADDITIONALS:

Control of unanswered/missed calls from guests to reception and other hotel services to facilitate the
communication with the guest at the time when the service can be provided, by sending a record of
internal calls made. The processing of this information will be carried out in a specialised manner
through pmslink and its call accounting tool.
Consumption of minibar items. The hotel staff in charge of minibar management will communicate the
consumption of articles to the PMS to be included it in the guest’s invoice. This is done through the room’s telephone, by dialling different codes for each article consumed.
Sending a record of calls received from outside, basically for call accounting system controls.
Activation of ‘Do Not Disturb’ status by the guest to be broadcast to different hotel services. Usually
by dialling codes on their terminal, using a specific table and/or using terminals with a multi-function
display.
Programming / cancellation of the wake-up calls by the guest. Usually by dialling codes on their
terminal or using terminals with a multi-function display.

API Methods and their relationship to PBX System features and data:

pmslink → PBX System

I. Action CHECKIN:

Guest arrival. Request sent at the moment of the occupation of a room and related to the features:

Assign main guest name to the extension, language, and other possible data.
Activate the making of outgoing calls at the level to be determined.
Cancellation of active wake-up calls associated to the extension, programmed in the previous stay, and not cancelled or carried out

II. Action UPDATE:

Modification of main guest or Stay data. Request sent in the case of data modification and related to
the features:

Assign guest name to extension, language, and other possible data.

III. Action MOVE:

Change of extension. Request sent in the case of a room change and related to the features:

Transfer basic configuration from source extension to destination extension: Name, language, other guest data, call restrictions.
Transfer of associate services from source extension to destination extension: Do Not Disturb, message waiting, wake-up calls.

IV. Action CHECKOUT:

Guest checkout. Request sent at the time of leaving a Room and related to the features:

Assigning the physical address of the extension as the name of the extension. Deleting of other associated data.
Restrict the making of outgoing calls.
Eliminate additional associated services: Message Waiting, Do Not Disturb

Since there may be cases of CHECKOUT prior to the guest’s departure, normally in the early hours of the morning
and to facilitate mass departures, possible active wake-up calls should NOT be cancelled.

V. Action WAKE:

Setting / cancellation of wake-up calls.

Activate / cancel wake-up call. Normally, given the purpose of this service, only one wake-up call is allowed to be activated per extension, so the activation of a new wake-up call would cancel possible active wake-up calls previously done.
Usually, the activation / cancellation of a wake-up call generates a specific message from the PBX system, as confirmation of the action.

VI. Action DND:

Activation / cancellation of ‘Do Not Disturb’ status.

Activate / cancel the status.

VII. Action WMSG:

Activation / cancellation of message waiting.

Activate / cancel the message waiting’s indicator.

VIII. Action COS:

Assignment of call making restriction level (Class Of Service).

Assigns level to the extension.

IX. Action SMDR:

Request for messages and data to be sent by the PBX system (Station Message Detail Recording).

Because the PBX system assumes only the role of http server (by default), the data to be transmitted to pmslink
must be stored temporally until pmslink makes a request to obtain it.

Hereby the PBX system will have to:

Store internally and temporarily the data to be sent.
Attend the GET requests made by pmslink, returning the pending data since the last request.
Update the internal control of data already sent, deleting the temporary storage of each request.

Data that can be sent:

Dialling of cleaning codes (housekeeping).
Dialling of article codes consumed in the minibar.
Wake-up calls results.
Records of calls made to the outside (outgoing calls).
Records of internal calls (Internal calls).
Records of calls received from outside (incoming calls).
Records of wake-up activation / cancellation.
Records of ‘Do Not Disturb’ activation / cancellation.

Connection Methods

Protocol:

HTTP o HTTPS as supported by the PBX system server.

HTTPS is recommended in all cases and especially in the case of Cloud PBX systems

URLs:

The HTTP/HTTPS server of the PBX system shall provide endpoints for the different actions and data requested
by pmslink. These endpoints may be:

Common for all requirements. The details of the action and data needed shall be included in the body
of the request. Example: https://pbx.api.com.
Specific for each requirement: Each action or request must be directed to a specific endpoint. Example:
https://pbx.api.com/checkin, https://pbx.api.com/move.

In all cases the detail of the action and necessary data will be included in the body of the request.

Data formatting:

JSON in all cases.

The real formatting will be using ‘integer’ + separation (‘.’) + ‘decimal’ using two digits. Example: 123.50.

Date values will be expressed in format “YYYY/MM/DDTHH:MM:SS” and will refer to the local time (and time
zone) for each installation. Ex: 01/01/2050 at 10:30 = 20500101103000.

The language codes used will be the ones according to ISO 639-1.

Authentication:

HTTP BASIC AUTHENTICATION: authentication done using user / password according to RFC 7617 specifications.

Note: Exists other possibilities to authenticate if it is needed. Please contact us.

HTTP commands:

POST in all cases, indicating in the body the necessary parameters for its execution in JSON format.

Confirmations and replies:

400 – Bad Request. – The information cannot be processed due to a syntax error.
401 – Unauthorized. – Authentication error.
403- Forbidden. – Error with the data received.
500 – Internal Server Error. – Process cannot be done due to an internal error.
200 – OK in the rest of the cases. JSON structure will be returned with details of the execution of the request, with the following parameters:

Name	Type	Value
code	integer	Result code to be defined by the PBX system. The code ‘0’ will indicate request made.Codes greater than 99 will indicate that the action could not be performed dueto temporary causes and pmslink must retry the sending. E.g.: system busy.Codes between 0 and 99 indicate that the action is not possible in any case and the request will be rejected indefinitely under the current circumstances. E.g.: Extension does not exist.
description	string	Result description.In case of an error, it must be descriptive enough to be interpreted correctly by pmslink technical support in order to resolve or communicate with the PBX system for the resolution.

EXAMPLE: POST

{"code": 0, "description": "success"}

Connection control:

char pmslink will keep a buffer (FIFO method) as a queue for pending information to be sent in the following
cases:

Physical linking errors with the integrated system server.
Actions that return the following codes: 400, 401 and/or 500. Those are addressed as one-time errors. Which will be assumed that will be recovered by the server or settings adjustments that will allow the process.

In case of connection errors, char pmslink will retry to resend in a programmed frequency all the information on that queue.

PMS > PBX System

Checkin Action

Sent by the PMS through char pmslink to the PBX system integrated during the guest’s arrival.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	CHKI
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Extension name	YES	string	extension_name	Value to be assigned as the name of the extension to be shown literally on the display of the terminal that answers the guest calls
Guest’s name	–	string	name	Name of the main guest to be shown literally on the display of the terminal handling guest calls.
Guest’s surname	–	string	surname	Surname of the main guest to be shown literally on the display of the terminal handling guest calls.
Language	–	string	language	Language code (ISO 639-1): * For use in voice guides and messages * To be shown on the display of the terminal handling guest calls.
VIP level	–	string	level	VIP level to be shown literally on the display of the terminal handling guest calls.
Arrival Date	–	string	arrival	Arrival Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Departure Date	–	string	departure	Departure Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Class Of Service	–	string	cos	Restriction level for making telephone calls according to the PBX system configuration.

Example: POST

Request

{
    "action": "CHKI",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "extension_name": "John Doe",
    "name": "John",
    "surname": "Doe",
    "language": "EN",
    "level": "VIP",
    "arrival": "2050/21/09T15:00:00",
    "departure": "2050/30/09T12:00:00",
    "cos": "1"
}

Response

{
    "code": 0,
    "description": "success"
}

Update Action

Sent by the PMS through char pmslink to the PBX system during a guest data modification.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	UPDATE
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Extension name	YES	string	extension_name	Value to be assigned as the name of the extension to be shown literally on the display of the terminal that answers the guest calls
Guest’s name	–	string	name	Name of the main guest to be shown literally on the display of the terminal handling guest calls.
Guest’s surname	–	string	surname	Surname of the main guest to be shown literally on the display of the terminal handling guest calls.
Language	–	string	language	Language code (ISO 639-1): * For use in voice guides and messages * To be shown on the display of the terminal handling guest calls.
VIP level	–	string	level	VIP level to be shown literally on the display of the terminal handling guest calls.
Arrival Date	–	string	arrival	Arrival Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Departure Date	–	string	departure	Departure Date and Time using the format YYYY/MM/DDTHH:MM:SS to be shown in standard format on the display of the terminal handling guest calls.
Class Of Service	–	string	cos	Restriction level for making telephone calls according to the PBX system configuration.

Example: POST

Request

{
    "action": "UPDATE",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "extension_name": "John Doe",
    "name": "John",
    "surname": "Doe",
    "language": "EN",
    "level": "VIP",
    "arrival": "2050/21/09T15:00:00",
    "departure": "2050/30/09T12:00:00",
    "cos": "1"
}

Response

{
    "code": 0,
    "description": "success"
}

Move Action

Sent by the PMS through char pmslink to the PBX system during a room change.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	MOVE
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
Origin PBX extension	YES	string	extension_id	Origin extension in the PBX system. May or may not match the room.
Destination PBX extension	YES	string	destination_id	Destination extension in the PBX system. May or may not match the room.

Example: POST

Request

{
    "action": "MOVE",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "destination_id": "2003"
}

Response

{
    "code": 0,
    "description": "success"
}

Checkout Action

Sent by the PMS through char pmslink to the PBX system at guest’s departure.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	CHKO
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.

Example: POST

Request

{
    "action": "CHKO",
    "hotel_id": "myhotel",
    "extension_id": "1001"
}

Response

{
    "code": 0,
    "description": "success"
}

Cos Action

Sent by the PMS through char pmslink to the PBX system in order to apply a Class of Service.

COS action is to restrict or allow calls on the PBX’s extension.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	COS
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Class Of Service	YES	string	cos	Class of Service to be assigned, according with PBX system.

Example: POST

Request

{
    "action": "COS",
    "hotelid": "myhotel",
    "extension_id": "1001",
    "cos": "3"
}

Response

{
    "code": 0,
    "description": "success"
}

DND Action

Sent by the PMS through char pmslink to the PBX system indicating that the guest would like/would not like
to receive communications, for example phone calls or hotel services.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	DND
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Do Not Disturb status	YES	boolean	active	Activated (true), Deactivated (false).

Example: POST

Request

{
    "action": "DND",
    "hotel_id": "myhotel",
    "extension_id": "1001",
    "active": true
}

Response

{
    "code": 0,
    "description": "success"
}

WMSG Action

Sent by the PMS through char pmslink to the PBX system reporting that there are messages to be
transmitted/sent to the guest.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	WMSG
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Waiting message status	YES	boolean	active	Activated (true) Deactivated (false).

Example: POST

Request

{
    "acrion": "WMSG",
    "hotel_id": "myhotel",
    "extension_id" : "1001",
    "active": true
}

Response

{
    "code": 0,
    "description": "success"
}

Wake Action

Sent by the PMS through char pmslink to the PBX system in order to setup/cancel a wakeup call.

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	WAKE
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Wake up action	YES	string	wake_action	S: Setting up. C: Cancellation.
Wake ID		string	wake_uid	Wake up unique ID.
Wake up time	YESY	string	wake_time	Wake up date-time (YYYY/MM/DDTHH:MM:SS)

Example: POST

Request

{
    "action": "WAKE",
    "hotelid": "myhotel",
    "extension_id": "1001",
    "wake_action":"S"
    "wake_uid": "12345",
    "wake_time": "2050/09/21T09:00:00"
}

Response

{
    "code": 0,
    "description": "success"
}

GET_SMDR Action

Sent by char pmslink as request to the PBX system regarding pending actions and data to be sent to the PMS
(stored on queue such as phone calls, charges, status.).

In the case of having messages to be processed, the PBX system will provide (maximum) 100 messages per
request and will delete them from its queue list.

In the case of having and empty list, it will confirm the processing using the code HTTP 200 (OK) with its result,
without including data into the reply.

Request

Data	Mandatory	Type	Name	Value
Action ID	YES	string	action	GET_SMDR
Hotel ID	(YES)	string	hotel_id	Hotel’s ID for each installation. Mandatory on multi – hotel scenarios.

Reply

Data	Mandatory	Type	Name	Value
Result code	YES	integer	code	Result code
Result description	YES	string	description	Description of the result. Example: “data” o “no data”.
SMDR list	YES	string	SMDR	Identifier of the array of objects containing the different data records.
Data type	YES	string	smdr_type	C: Phone call P: Charge mini bar S: Room status code W: Wake up message D: Do Not Disturb status
Date – time	YES	string	datetime	Date – Time of record creation in format YYYY/MM/DDTHH:MM:SS
PBX Extension	YES	string	extension_id	Identifier of the extension in the PBX system. May or may not match the room.
Specific data according to Data Type	YES	string	data	Identifier of the object containing the specified data according to Data type.

Data and structure will depend according to the Data Type

Example: POST

Request

{
    "action": "GET_SMDR",
    "hotelid": "myhotel"
}

Response

{
    "code": 0,
     "description": "data",
     "SMDR":
    [
        {
            "smdr_type": "C",
            "datetime": "2050/09/21T14:29:34",
            "extension_id": "1001",
            "data":
                {
                    "call_type": "O",
                    "line": "SIP_ 12345",
                    "connected": "90985630987642",
                    "response": 4,
                    "duration": 98,
                    "units": 25,
                    "cost": 14.23
                 }
        },
        {
            "smdr_type": "P",
            "datetime": "2050/09/21T14:41:12",
            "extension_id": "1002",
            "data":
                 {
                    "post_type": "M",
                    "article": "32"
                 }
        },
        {
            "smdr_type": "S",
            "datetime": "2050/09/21T14:42:21",
            "extension_id": "1002",
            "data":
                {
                    "room_status": "2",
                    "maid": "45"
                }
        },
        {
            "smdr_type": "W",
            "datetime": "2050/09/21T14:44:32",
            "extension_id": "2002",
            "data":
                {
                    "wake_type": "E",
                    "wake_uid": "28390405872567384747",
                    "wake_time" : "2050/09/22T09:00:00"
                }
        },
        {
            "smdr_type": "D",
            "datetime": "2050/09/21T14:49:20",
            "extension_id": "2009",
            "data":
                {
                    "active": false
                }
        }
    ]
}

Specific data according to Data Type

‘C’ – PHONE CALL data

Phone call data and structure (for charging and/or communication’s registry) received as part of the reply for
Action GET_SMDR (Data Type ‘C’).

Data	Mandatory	Type	Name	Value
Phone call type	YES	integer	call_type	O: Outgoing call I: Incoming call L: Internal outgoing call
Line		string	line	Type of Phone’s link used
Phone Number	YES	string	connected	Outbound: Called, external destination Inbound: Caller, external origin Internal: Called, internal destination
Response time		integer	response	Response time in seconds
Call duration	YES	integer	duration	Call duration in seconds (0 = not answered)
Call accounting units		integer	units	Charge units (outgoing call).
Phone call cost		real	cost	Phone call cost (outgoing call).The assignment of the cost of a call will be made:1. Assigning the value ‘price’2. Calculating ‘units’ x Price per unit configured in pmslink3. According to tariffs configured in pmslink based on call destination (connected) and call duration.

‘P’ – CHARGE data

Charge Minibar received as part of the response for Action GET_SMDR. (Data Type ‘P’).

Data	Mandatory	Type	Name	Value
Charge type	YES	post_type	action	M: Minibar
Article	YES	string	article	Article code dialled on the room’s telephone for the service

‘S’ – ROOM STATUS data

Room status data and structure received as part of the response for Action GET_SMDR. (Data Type ‘S’).

Data	Mandatory	Type	Name	Value
Room status	YES	string	room_status	Room status code dialled on the room’ telephone for the service.
Worker/Maid		string	maid	Worker/Maid ID code.

‘W’ – WAKE UP data

Wake Up data and structure received as part of the response for Action GET_SMDR. (Data Type ‘W’).

Data	Mandatory	Type	Name	Value
Message type	YES	string	wake_type	S: Setting up C: Cancellation E: Executed F: Not answered/failure
Wake up UID		string	wake_uid	Wake up unique ID.
Wake up Time	YES	string	wake_time	Wake up Date-Time in format YYYY/MM/DDTHH:MM:SS

‘D’ – DO NOT DISTURB (DND) data

Do Not Disturb (DND) data and structure received as part of the response for Action GET_SMDR. (Data Type e “D”).

Data	Mandatory	Type	Name	Value
Do Not Disturb status	YES	boolean	actvive	Activated (true), deactivated (false).

2. char pmslink HTTPCNX API FOR PBX

22/07/2021.Version for PBX based on general API.

Description

Development process, testing, certification and realease

Data flow and basic functionalities

The functionality offered by the PBX system is, or may be, related to:

Features provided by the PBX system to the hotel through the integration:

Data provided by the PBX system to the hotel through the integration:

API Methods and their relationship to PBX System features and data:

pmslink → PBX System

Connection Methods

Protocol:

URLs:

Data formatting:

Authentication:

HTTP commands:

Confirmations and replies:

Connection control:

PMS > PBX System

Checkin Action

Example: POST

Request

Response

Update Action

Example: POST

Request

Response

Move Action

Example: POST

Request

Response

Checkout Action

Example: POST

Request

Response

Cos Action

Example: POST

Request

Response

DND Action

Example: POST

Request

Response

WMSG Action

Example: POST

Request

Response

Wake Action

Example: POST

Request

Response

GET_SMDR Action

Request

Reply

Example: POST

Request

Response

Specific data according to Data Type

‘C’ – PHONE CALL data

‘P’ – CHARGE data

‘S’ – ROOM STATUS data

‘W’ – WAKE UP data

‘D’ – DO NOT DISTURB (DND) data

22/07/2021.
Version for PBX based on general API.