...
| Erweitern | ||||
|---|---|---|---|---|
| ||||
Find out how to manage users from your system with hotelkit and how to compare the user base of both systems. You get familiar with creating and updating users in hotelkit. At the end you find a first introduction on a special case when muliple businesses share employees.
|
...
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 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.
Process
User Synchronization
...
Additional updates can be send sent each time a user is edited in the partner, wether it’s an attribute or the activation status.
...
Each time hotelkit passes users back to the partner on a GET-call the partner has to iterate through each user internally to match the user.
...
The user matching is easiest made by ‘clientID’.
If ‘clientID’ is not given or null the matching should be done by name, mail and/or birthdate of the user.
We recommend name and birthdate or e-mail if all users have an individual mail at the partner.
ID vs. clientID
For every user there are two identifier:
...
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 sent for deactivation, the property can decline the deactivation. It should be ensured that the deactivation is only 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.
Handling an ignored User
...
Changing the status of an ignored user has to be done manually by the property.
Pagination
With API version 3.1 we provide pagination for user listing, which returns a subset of users.
...
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.
| Macro openapi | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||