> ## Documentation Index
> Fetch the complete documentation index at: https://docs.recepai.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# RecepAI reads your PMS
> The conditions a PMS read interface must meet, and what Hotel Linkage needs from your hotel and your PMS vendor, for RecepAI to connect by reading your guest list.
With this method, Hotel Linkage connects to your PMS's read interface and reads your in-house guest list on a schedule. RecepAI only reads. It never writes to your PMS.
**How it works, in one sentence:** you and your PMS vendor provide access and the information on this page; Hotel Linkage assesses the interface against the conditions below and, once every condition is met, builds and operates the connection on the RecepAI side. Your PMS vendor's part is access, documentation, and any support or change needed on the PMS side.
This page is the list of what we need and the conditions the interface must meet. Send it to your PMS vendor as it stands.
## 1. Access
| Item | Provided by | Required |
| -------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------ |
| Address and documentation of the PMS read interface | PMS vendor | Yes |
| A read-only service account dedicated to RecepAI | PMS vendor or hotel | Yes |
| The property identifier(s) that account is tied to | PMS vendor | Yes |
| Our server addresses added to the PMS's allow-list, if the PMS restricts access by network address | PMS vendor | Yes, where such a restriction exists |
| Session lifetime and how a session is renewed | PMS vendor | Yes |
**The service account must be dedicated to RecepAI.** A staff member's own login stops working the day that person leaves, and the connection stops with it.
If your PMS restricts access by network address, tell us before the first connection attempt. A PMS with that restriction refuses the connection before it looks at the credentials. When the PMS response identifies a network allow-list refusal, RecepAI reports it separately from a credential problem; otherwise Hotel Linkage asks the PMS vendor to confirm the cause. Either way the addresses have to be allowed on the PMS side before anything else can be tested. Hotel Linkage provides the addresses.
If your hotel has more than one property in the same PMS, we need the identifier of each property we should read.
## 2. The guest list
We read the list of guests currently in the hotel. The list must return **one row per person**, not one row per room, and each row must carry the following.
| Field | Required | How RecepAI uses it |
| -------------------------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------- |
| Room number | Yes | The room the guest is served in |
| Reservation identifier | Yes | Groups the people staying on one booking |
| A stable identifier for the **person** | Yes | Two people sharing a room must be distinguishable. A reservation number does not do this on its own |
| First name and last name | Yes | Recognition and greeting for adults. For a child, only the surname and the age are kept — see below |
| Arrival date | Yes | Shown as the guest's arrival; never assumed |
| Departure date | Yes | The end of the stay |
| Departure time | Yes | A stay ends when your hotel says it ends, not at a time we choose |
| Adults, children and infants — counts | Yes | Occupancy shape |
| Children's ages | Yes, when children are present | A child is recorded by surname and age |
| Nationality | Yes | Recorded with the stay |
| Phone | When held | Service messages, where the conditions in section 6 are met |
| E-mail | When held | Recorded with the stay for the guest's profile |
| Date of birth | When held | Distinguishes adults from children |
**Children.** For a guest under 18 at arrival, RecepAI keeps the surname and the age and does not keep the first name, the date of birth, the phone number or the e-mail address, even when the PMS returns them.
**Contact details.** A phone number or e-mail address read from the PMS is treated as **the hotel's record**, never as proof that the guest holds it. Guests still confirm their own number before any personal information is shown to them, and no marketing message is sent on the strength of a PMS record. See [Guest data protection](/ai-manager/account/guest-data-protection).
## 3. Reservation status and changes
Reading the in-house list on its own is not enough, and this is the condition most often missed. Every item below is required.
| Item | Required | Why |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | ------------------------------------------------------------------------------------ |
| A reservation source that returns each reservation with its status — at least **expected arrival**, **in-house** and **checked out** — including reservations that are temporarily **not** on the in-house list | Yes | A checkout is read from the status, never inferred from a guest's absence |
| A way to learn changes: either a query for reservations updated since a given time, or a notification when a reservation changes — covering check-in, check-in cancellation, room move, status change and checkout | Yes | Without it, a room change or an early departure is learned only on a later full read |
| Completeness: the total number of rows returned with the list, and paging we can walk to the end | Yes | Proves the list is whole rather than cut at a page boundary |
**Why the in-house list alone fails.** Many PMS products handle a room move as *cancel the check-in, change the room, check in again*. Between those two steps the guest is physically in the hotel and **absent from the in-house list altogether** — there is no row to read a status from. A source that still returns that reservation, now in an expected-arrival state, and a change mechanism that reports the cancellation, are what make the guest visible for the length of the gap. That is why these are conditions rather than preferences.
## 4. What we do not keep
The following are not imported, not used and not stored by RecepAI:
* Passport numbers and national identity numbers
* Card and payment details
* Folio and account movements
If your PMS can leave these fields out of the service account's view, please do so. If the interface returns them anyway, they are discarded when the guest record is built and never reach the roster or a guest profile.
## 5. Questions we will ask your hotel
These are answered by your operations team, not by the PMS vendor.
* How does reception perform a room change in the PMS? (See the note in section 3.)
* What is your standard checkout time?
* What is the hotel's time zone?
* Does the read interface limit how often it may be called? RecepAI reads the list **every 15 minutes**.
## 6. How the connection goes live
Hotel Linkage reviews the interface documentation against sections 1–3 and tells you whether every condition is met, and what would be needed on the PMS side if one is not.
Hotel Linkage connects with the service account and reads the list once. A refused connection is reported to you with its cause.
For a few days RecepAI reads the list without acting on it, so that the data can be checked for consistency: rows that appear and disappear, rooms that change, counts that agree with the front desk.
On a day agreed with you, RecepAI starts serving the guests on the list. Guests already in the hotel at that moment are **not** messaged. A guest who arrives after it is eligible for the welcome message when the welcome message is switched on for your hotel, the guest is an adult, and a usable phone number is held for them. RecepAI checks eligible arrivals on its next scheduled welcome run. Being eligible is not the same as being messaged: a phone number shared by several guests is greeted once, a switched-off channel is skipped, and a messaging provider may refuse a send.
The list is read every 15 minutes. Arrivals appear on [Active Guests](/front-desk/guests/active-guests); departures leave it.
## Who to contact
Send this page to your PMS vendor and give Hotel Linkage a technical contact on their side. We can speak with their team directly. Questions about the connection itself go to [Getting help](/ai-manager/account/getting-help).