Skip to main content
This is a hotel guest management system, and as such, contains sensitive information such as Guest names, contact information, and stay details. As such, you must be very protective of this information, including following local laws and regulations, such as GDPR. Do not request nor store information you do not need, such as Guest names, etc. In addition, please be careful of where you might be exposing PII, such as in your logs - always mask or redact any and all PII, including names, email addresses, and phone numbers. We may later add a kyc-contains-pii response header when we know there is PII in the response.

​
GDPR and Guest Anonymization or Deletion

KYC supports advanced Guest Anonymization and Deletion functionality, usually in response to either a guest request or time-based policies. When this happens, the Guest record will still exist inside KYC, but will not be returned in any GET by ID or in any find or search operation.

​
Guest Merging

KYC also merges guest records from time to time, usually because duplicate records have been created, often from different properties, sales channels, etc. When this happens, a single guest record will become master and its ID the primary one used, however, all merged-in guest IDs will also still work forever. This means that if you retain a guest ID on your side and refer to it later after a guest merge, it will still work, however, be aware that if you query that guest, the returned ID itself may have changed. For example, you may query: GET /guest/1234 and the returned Guest record may be: {“id”:”5678”, “first_name”:”bob” …} Note that the guest record will NOT return the old merged IDs.

​
Historical Data

Some KYC APIs may restrict access to historical data, as this is generally not necessary for 3rd parties to use for ongoing operations.