Seitenvergleich

...

...

User Model in hotelkit

First it is important to understand how user activation in hotelkit works: Users can have different states in hotelkit.

...

If a vendor submits a new user, it will only be proposed to the property. The property then must either connect the user to an already existing user within hotelkit, create a new user (and attach some access) or ignore the user in hotelkit. If the property decides to make the user available in hotelkit the user is available at GET /users. Until then the user is available at GET /users/byStatus/pendingNew. In both cases the user’s attributes can be updated via PUT /users/ID. If the property decides to ignore the user, its data can only be seen at GET /users/byStatus/ignored to prevent a new proposal by the partner.

In case a user is send sent for deactivation in hotelkit by the partner, this change is also proposed to the property. The deactivation can be declined and the user remains active in hotelkit and listed in GET /users. In this case the deactivation should not be send again, as this would trigger a new proposal for deactivation.

...

Additional updates can be send sent each time a user is edited in the partner, wether it’s an attribute or the activation status.

...

By default, the recipients of imports are managed within hotelkit, for each request type the customer is able to select recipients (a single person, multiple person or groups). The recipients can also be adjusted anytime. This ensures that the information is forwarded to the correct employees even with a high rate of employee turnover. The partner does not need to handle the employees in general.
This approach would not be suitable, whenever the partner needs to send information specifically to one person at a time. A common use case is the import of salary information or a notification about pending actions at the partner.

...

For enabling a partner to act as an identity provider in a Single Sign on Scenario, the partner must provide the identity attributes for a user to hotelkit. For in depth process of the implementation, please refer to the “Use Cases” section.

Interactions with user endpoints

List User

The partner will get all available user of the customer.

Exceptions

A user is not listed as soon as he has no access to the customer anymore. Additionally, the customer can flag a user specifically as a user who is not available for the partnerhotelkit. See “Handling an ignored User”.

Deactivating a User

If a user gets deactivated in the partner (access is revoked) this change shall reflect in hotelkit by updating the user via PUT /users/{ID} and setting the attribute customerList to be empty “customerList”:[].

Eventough the user is send sent for deactivation, the property can decline the deactivation. It should be ensured that the deactivation is only send sent once.

To ease this case you can send updates to hotelkit whenever an attribute or the status in the partner changes. By this, you don’t have to check for activation status in the shown matching process above.

...

In chain solutions it may be useful to call GET /users from the higher-level administration customer to ensure getting all customer. If a user is activated, the user will return in the result of customerList. An user will only contain the customer itself and every customer with a lower level.
This case is described in more detail in the section User Synchronization for Multi-property Cases.

Endpoint-Documentation

Information about the usage of headers and the signature is found in Getting Started and Security.