...
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:
...
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 for deactivation, the property can decline the deactivation. It should be ensured that the deactivation is only send 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
A user gets ignored by a manual action of the property within hotelkit by changing the user from being pendingNew to ignored. This change will reflect in the next user synchronization iteration in the user not listed in GET /users/byStatus/pendingNew anymore. There is no action from your side needed.
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.
...