...
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 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
...