Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

Erweitern
titlePage Summary and Index

This page gives a practical example to status management between hotelkit and your system.

Check necessaties and a step by step walkthrough.

Inhalt
stylenone

...

Characteristics

Importing of tasks comes with special characteristics as a task can change its status and has a workflow to follow. The partner can import the tasks, created in his system, to hotelkit where the customer then can process it the same way as if it was in the partners system. The status changes will be pushed back to the partner. That way the partner controls the workflows as if the tasks was handled in his backend system.

...

Codeblock
PUT /setup/requests
{
    "type":"guestRequest",
   
    "labelForCustomer":{
        "de_DE":"Gästewunsch",
        "en_US":"Guest request"
    },
    "content":"true",
    "link":"true",
    "title":"true",
    "referenceID":"true",
    "attachements":"false",
    "enabledByDefault":"true",
    "text":false,
    "sendRecipients":false,
    "hasActions":true
}

Enable Request

Before sending requests to a client, the requestType must be enabled for the respective client.

Codeblock
PUT /setup/customer
{
    "enabledRequests":["guestRequest"]
}

To check imports in your test-environment, please make sure you are set as a recipient to read the import. This only applies in the test-environment.

Task Import

At first the task will be created at POST /requests and after that the status may be changed several times.

...

Codeblock
POST /requests?type=guestRequest
{
    "title":"Extra towel in room #404",
    "content":{
        "Comment of guest":"Please in XL"
    },
    "link":"https://hotelkit.net/demo/123", //link to partners details
    "referenceID":"123",
    "actions":[
        {
            "type":"dodecline",
            "label":"DoDecline",
            "labelDone":"DoneDeclined",
            "labelType":"successerror",
            "isDone":true,
        },     "information":{
   {             "typetext":"decline",{
               "label":"Decline",     "required":true,
       "labelDone":"Declined",             "labelTypetype":"errortext",
            "isDone":true,
            "informationlabel":{"Reason"
                "text":{}
            }
        "required":true,}, 
        {
            "type":"textaccept",
            "label":"Resolve",
            "labellabelDone":"ReasonCompleted",
            "labelType":"success",
   }         "isDone":true
   }
        },
    ]
}

Getting Status Changes

The customer may now trigger an action with the buttons “Do” and “Accept” or “Decline”. As “Decline” requests some more information (text), it will be triggered for documentation purposes.
As soon as a button is pushed, a request to the webhook is triggered:

...

If the status change was handled by the partner a 200 response must be sent to finish the synchronization. If there are no follow up actions available, there is no payload.

Follow up actions means that there are new possible states for the request.
The follow up actions will be returned in the response:

Codeblock
> 200 OK
{
    "actions":[
        {
            "type":"reopen",
            "label":"Reopen",
            "labelDone":"Open",
            "labelType":"error",
            "isDone":false,
            "information":{
                "text":{
                    "required":true,
                    "type":"text",
                    "label":"Reson for reopening"
                }
            }
        }
    ]
}

More Details on cinfigurations of actions can be found in the previous chapter Status Management