Push Order Status Change Signal
This signal will be pushed when the order status changes. After receiving the signal, the docking party needs to call Reservation Detail Interface to obtain the current status of the order according to the message content. Order Status Enumeration Dictionary.
Push Protocol#
https POST
Huazhu side request timeout request.timeout = 3s
Description#
Push parameters#
| Parameter | Type | Required | Maximum length | Example | Description |
|---|---|---|---|---|---|
| hotelId | String | Y | 32 | 12 * * 567 | Hotel ID |
| type | String | Y | 20 | Push data type, Enumeration Dictionary | |
| resId | String | Y | 64 | Reservation number | |
| timestamp | Date | Y | - | Change timestamp, format: yyyy-MM-dd HH: mm: ss.fff | |
| echoToken | String | Y | 20 | UUID is used by both parties to locate the problem |
[failure retry]:
1. after the request fails for the first time, it will be retried immediately
2. if the request fails for two consecutive times, it will enter the failure message queue and delay sending
3. tasks in the failure queue will increase the call interval one by one according to the number of retries, and will not be retried after more than 10 times. The docking party should consider judging whether the current message is the latest data according to the timestamp (timestamp) to avoid historical messages overwriting the latest status.
Response parameters#
| Parameter | Type | Required | Maximum length | Example | Description |
|---|---|---|---|---|---|
| status | String | Y | 10 | 1 | Status code, 1 successful,-1 failed |
| errorcode | string | N | 50 | defined by the interfacing party | |
| errormsg | string | N | 500 | The docking party defines it by itself and needs to clearly describe the cause of the problem |