Guest Data Stops at the Channel: What Still Arrives

When a channel stops passing guest phone numbers, the booking still arrives. Four things come with it, and one thing does not.

Last updated: October 31, 2026

When a channel narrows what it shares about a guest, the booking still lands in your calendar with everything you need to run the stay. Four things come with it: the reservation and its reference, the name on it, the stay details, and the channel's own message thread. What can disappear is the contact layer on top. Plan the arrival around the thread, and a missing field stops being a nine o'clock problem.

Key Takeaways

• A booking record has a core and a layer. The core is who, when and how much. The layer is how you reach them, and that part isn't yours to keep.
• Four things still arrive. The reservation, the name on it, the stay details and the channel's thread all come through as before.
• The thread replaces the call. An arrival that used to run on a phone call has to run on a message the guest can see in the channel.
• Masking isn't a workaround. Hiding contact data in your own records is about the copies you hold, not about recovering a field the channel no longer sends.
• Write down what didn't arrive. A dated note about the gap is what turns a one-off surprise into an operating rule.

What the channel still sends

Think of a reservation as two layers stacked on each other. The bottom layer is the booking core: who booked, how many guests, which nights, what rate, what they asked for. That core is what a host actually needs to run a stay, and channels keep sending it because the stay can't happen without it.

The top layer is contact. A phone number for the arrival call. An address for the taxi. A name to put against the door code. This is the layer a platform can change unilaterally, because it doesn't stop the booking from functioning. It only stops one particular way of running the arrival.

So four things still come through with a normal booking. The reservation itself, with the reference the channel issues. The name the guest booked under. The stay details: dates, occupancy, nightly rate and total. And the channel's own thread, which is where the guest has been talking to the platform all along.

Two of those deserve a closer look, because hosts routinely overestimate them.

The name can be partial. A first name and an initial is enough for a booking and not enough for a nameplate, and it's worth knowing that before you print one.

The thread lives where the booking lives. localsbnb.com carries Airbnb, Booking.com, Agoda and Trip.com on one calendar, and the guest inbox inside it covers Airbnb conversations. A Booking.com booking still appears on the calendar with its own thread sitting in that channel, which is fine as long as you know which window to look in on the morning of an arrival.

The field that disappeared

Here's the published change, once, with its source. Booking.com stopped passing guest phone numbers to accommodation partners from 28 September 2026, as reported by eHotelier.

That sentence explains a week of confused arrivals. Everything a host used to do with a number — confirm a landing time, send a door code, arrange a late check-in — was built on a field that is no longer in the record. None of those tasks has become impossible. They've just changed address.

Whether the policy is the right one for guests is a question for the platform and its regulators. It isn't a question a host can settle, and treating it as one costs evenings you could spend rebuilding the arrival routine.

What matters operationally is narrower. A record without contact details isn't an incomplete booking. It's a booking that expects the host to use the channel's own channel. If your process assumes otherwise, the assumption is the thing that broke, not the reservation.

Where a masking layer helps

There's a separate problem sitting next to this one, and it's easy to mix them up. Your own records hold guest names, phone numbers and ID numbers, and those are the details that turn a routine booking into a liability when a laptop is lost or a staff member leaves.

LOCALSBNB masks guest names, phone numbers and ID numbers automatically, so the working view of a reservation shows what a host needs and not the full identifiers underneath. That's the point of masking: fewer copies of the sensitive part, in fewer places, for less time.

What masking isn't is a way around a channel's decision. If a platform stops sending a field, a masking layer in your own system doesn't recreate it, and no host should be running a process that assumes it might. The two things solve different problems. One limits what you keep. The other is a fact about what you're given.

Keep them separate and each is simple. Mix them up and you'll spend a week asking software to solve a policy question.

What to record instead

The rebuild is small. Swap the arrival call for an arrival message, and put it where the guest is already looking.

Send the check-in detail inside the channel's thread, not to a number you don't have. Ask the guest to confirm their arrival window in the same thread, so the answer sits next to the booking rather than in a personal phone. Where a door code is involved, use a method that doesn't need a live call: a lockbox code sent in the thread, or a key handover arranged in writing.

Then write the gap down. A short dated note in the booking — contact detail not supplied by the channel, arrival confirmed in thread — is what stops the next person on the account from re-solving the same problem from scratch.

And check the edges of the stay. Late arrivals, extra guests and access requests are the three moments where a host reaches for a number, and all three can be moved into the thread with a single template that asks the guest to reply there.

FAQ

Do I still get a phone number with a Booking.com reservation?

Not from the channel. That's the substance of the change described above, and it's worth reading as a permanent operating condition rather than a glitch. You can still ask a guest for a number in the thread, and many will give one, but the booking itself won't arrive with it.

Can I message the guest outside the channel thread?

Sometimes, and only if the guest moves the conversation there themselves. The reliable route is the thread, because that's where the record already sits and where a reply is expected. A message sent to an address the guest didn't offer is a message that may never be read.

Does masking make it harder to run an arrival?

No. Masking limits what a working view shows and what your records hold long-term. The arrival routine depends on the thread and the booking record, not on the identifiers underneath them, so the two changes don't collide.

The practical version of all this is a thread, a template and a dated note. localsbnb.com keeps the four channels on one calendar and masks the guest details it holds, so the arrival you plan on Monday is the arrival you can still run on Friday, with or without a number attached.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. What a channel shares with partners is set by that platform and can change again, and data protection rules differ by market. Check the current partner terms and the current rules where you operate before you change how you contact guests.