One Field Disappeared — and Your Entire Pre-Arrival Flow Broke
On September 28, 2026, [Booking.com stopped sending the guest's phone number](https://www.smoobu.com/en/?p=82327) to connected software — PMSs, channel managers, and every tool that sits downstream. The change applies worldwide, to new bookings, modifications, and cancellations. Some markets saw it earlier: [Japan lost the phone field back in June](https://support.airhost.co/en/articles/15885162-booking-com-related-why-isn-t-the-guest-s-phone-number-imported-into-airhost-reservations). If your hotel relies on automated SMS to send arrival instructions, door codes, check-in reminders, or upsell offers, that workflow is now dead for every Booking.com reservation. Reservations, rates, availability, and guest names still sync — but the one field that powered your guest communication is gone.
Why Booking.com Did This (and Why It Makes Sense)
The stated reason is phishing. Scammers were sending fake SMS and messages on platforms like WhatsApp that quoted real reservation details — guest name, dates, property name — and pressured travelers to pay again to "keep" their booking. By removing the phone number from the data feed, Booking.com cuts off the raw material those scams need. It's a defensible decision from a platform protecting 28 million listings. But the burden shifts entirely to hoteliers. You didn't cause the phishing. You still need to reach your guests before they arrive.
What Actually Breaks When the Phone Number Disappears
Think about every automated message your property sends between booking confirmation and check-out. SMS with parking directions. A text the morning of arrival with the door code. A pre-check-in reminder linking to your registration form. An upsell for a late check-out or breakfast package. All of those relied on a phone number your PMS pulled automatically from the Booking.com reservation. Now that number is blank. Your staff can still look it up manually — one booking at a time — inside the Booking.com Extranet or the Pulse app. For a 40-room boutique doing 15 Booking.com arrivals a day, that's 15 extra manual lookups, 15 copy-pastes, and zero automation.
The Proxy Email Problem Makes It Worse
The phone number isn't the only contact detail you've lost control of. OTAs already replaced the guest's real email with a proxy (relay) address. Messages you send to that proxy get forwarded to the guest, but you never see the real inbox. So now the hotel has no direct phone number and no real email. You're communicating through two layers of OTA infrastructure, hoping your messages arrive. If the proxy email bounces or the guest doesn't check that forwarded thread, you have no fallback. The guest shows up at midnight with no code, no instructions, and no way for your system to have reached them.
How LOXE Solves This — Step by Step
LOXE doesn't fight the proxy system. It works through it. When a Booking.com reservation lands in your PMS (Mews, Cloudbeds, Apaleo, Maestro, Reservit — whichever you use), LOXE sends the online check-in invitation to the proxy email address. Booking.com forwards that email to the guest's real inbox. The email contains a personal link to the LOXE web app — no app store download, no friction. When the guest opens the link, LOXE asks for their phone number and sends a one-time verification code via SMS. The guest types in the code, confirming the number is real and theirs. LOXE then asks for their real email address. Both verified fields — phone and email — are written back to the guest record automatically.
What Happens Next for the Guest
Once the guest has verified their contact info, they move through the pre-check-in steps your hotel has configured: arrival time, ID upload with a selfie verified by AI, credit card pre-authorization, and a digital registration card. On arrival day, LOXE sends the door code by SMS to the verified phone number. The guest walks in. No front desk queue, no manual lookup, no missing codes. Every upsell, message, and follow-up you send after that goes to a verified, direct contact — not a proxy. You own that relationship now.
Why This Actually Aligns with Booking.com's Goal
Booking.com removed the phone number to stop phishing — scammers exploiting raw data in automated systems. LOXE's approach doesn't re-expose that data in a feed. The guest voluntarily provides their phone number inside a secure, branded check-in flow they initiated by clicking a link in their own inbox. No bulk data dump, no third-party scraping risk. The hotel gets verified contact info because the guest chose to share it, inside a flow that benefits them (faster check-in, door code, no line). It's consent-based, not extraction-based. Over 500,000 check-ins have already been processed through LOXE — the pattern works at scale.
What You Should Do This Week
If Booking.com represents even 20% of your reservations, your pre-arrival automation is already partially broken. Here's what to do: audit your current SMS and messaging workflows to see which ones depend on the phone number from the PMS feed. Check how many Booking.com arrivals your staff is manually looking up in the Extranet each day. Then look at a system like LOXE that recovers verified contact info automatically, without fighting the OTA's proxy layer. Book a demo at [loxe.io](https://calendly.com/loxe/demo) — we'll show you exactly how this works with your PMS, your locks, and your Booking.com volume. The phone number isn't coming back. Your pre-arrival flow doesn't have to stay broken.