Locked out of the Booking.com extranet: login, verification code and reaching support

The extranet is the private site where a hotel manages its page, rates and reservations on the booking site. A lockout is often a verification problem rather than a password problem: the code goes to a phone or Pulse app registered on the account. Type the address yourself, then use the sign-in page's recovery route with the property ID.

It is 08:40, three arrivals are due before noon, and the sign-in page will not let anyone in. The verification code is going to a phone that left the hotel two managers ago. This article walks through the ordinary booking.com extranet login problem: what usually causes it, where the code is actually going, who should hold the main account, how to reach support, and how to run today's arrivals while access is down.

Why can't I log in to the Booking.com extranet today?#

A lockout comes down to one of four things: the wrong address, an old username saved in the browser, a verification code going to a phone nobody at the hotel holds, or an account that has sat unused long enough to be locked.

The extranet is the private site where the hotel manages its property page, rates, availability, reservations and guest messages on the booking site. Losing access means losing sight of what the site is selling on your behalf. That is why the first minutes matter.

Start with the address. Booking.com's own guidance says that if login errors occur, you should start again by typing admin.booking.com into the address bar yourself, rather than following a link in an email or a message (Booking.com Partner Hub, "Logging in to your Booking.com extranet", updated 4 November 2026). Treat any sign-in page reached from a link as suspect: a copied page is built to take hotel credentials.

Next, check what the browser filled in. Autofill often still holds a former employee's username, so the password looks wrong when the username is. Try a private window or a second browser to rule out extensions and stale cookies before concluding the account itself is broken.

Then separate a lockout from a takeover. A lockout gives you an error you can reproduce, and nothing else changes. A takeover gives you a password that suddenly fails alongside changes you did not make: a new user, an altered phone number, altered payment details, or bookings you cannot see. If anything points to a takeover, stop signing in and treat it as a security incident rather than an inconvenience. The steps for that situation are different, and they belong in your incident procedure rather than in this checklist.

Where is the verification code going?#

To whatever phone number or Pulse app is registered on the account, which is often not the person sitting at the desk.

Two-factor authentication is required: after the username and password, the user enters a PIN generated in the Pulse app or a code received by SMS (Booking.com Partner Hub, "Logging in to your Booking.com extranet", updated 4 November 2026). The site may ask for authentication several times, including multiple times within 24 hours, depending on the actions taken. A code that worked an hour ago does not mean you are done for the day.

On a new device the user chooses between a six-digit code by text message and the Pulse PIN, which the app generates. The app travels with the person; the SIM stays in whichever phone it was put in. Newly invited users must complete two-factor authentication too, so a user added without their own phone number cannot get in at all.

The site recommends keeping the Pulse app installed, keeping the phone number up to date and adding a backup verification number (same source). The backup number is easy to leave unset. Test the whole chain, from the front desk device to the code arriving, before a busy morning rather than during one.

Who should hold the main extranet account?#

The hotel, not a person: a role mailbox and a hotel-owned phone number for the account, with each staff member added as a separate user.

Booking.com advises against sharing login details and recommends adding several users with their own email addresses and phone numbers (Partner Hub, updated 4 November 2026). Sharing one login also makes the activity record useless: every change carries the same name, so nobody can tell who changed a rate or cancelled a booking.

Put the main account on a mailbox the hotel controls, for example a reservations address, and on a SIM the hotel owns and can physically find. A personal number is a single point of failure. Add each person as a user with their own email and phone, give only the rights the job needs, and remove the user on their last day rather than at the end of the month.

Keep the password in a password manager the hotel controls, never in a message, a shared document or a note beside the terminal. Write the rights down: who may change rates and availability, who may only read reservations, who may message guests. The same discipline applies to the property management system, where user roles decide what a person can see and do; a setup checklist for that is in PMS user roles and permissions.

How do I reach Booking.com support when I cannot get in?#

Through the sign-in page's own recovery route, with the property ID and a call from a number the extranet already knows.

A forgotten username or password is recovered from the sign-in page's "Having trouble signing in?" route (Partner Hub, updated 4 November 2026). When two-factor authentication cannot be completed, the user selects "Unable to verify?", picks a reason and contacts customer service with the PIN shown on screen to receive a new verification code (same source).

Support needs the property ID and a call from a number listed in the extranet. A call from an unknown phone cannot be verified, however urgent the morning is. The partner help pages can be read without signing in, which is where the rules on two-factor authentication, locked accounts and recovery are written; read them on the day, because they change.

Do not use a support number or address found in a search result, a message or an advertisement. Impersonation of support is a known route into hotel accounts. Everything in this section comes from the site's public partner help pages, read on the date given (opens in a new tab); naming the site implies no partnership or endorsement.

The account is in a former manager's name. What now?#

Treat it as an ownership problem rather than a password problem: the fix is to move the account onto contacts the hotel controls, not to keep borrowing someone's phone.

Accounts unused for more than six months are locked and accounts unused for more than 24 months are disabled, and in both cases Customer Service must be contacted (Partner Hub, updated 4 November 2026). An abandoned account may need support even when the password is known.

Asking a former manager for a code works once and leaves the hotel dependent. It also leaves guest data and rate control with someone who no longer works for you. Sequence the change instead: establish who may act for the property, move the account email and phone to hotel-controlled ones, add the current team as users, then remove the old users.

If the former manager is unreachable or unwilling, support is the route; expect to show that you act for the property. A change of ownership, where the property itself passes to a new operator, is a larger job than a staff departure and should be planned as a handover. Record the date of each change so the next person can see what happened and when.

What do I do about today's arrivals while I am locked out?#

Run the day from your own records, tell guests what you actually know, and fix access in parallel. Arrivals do not wait for the sign-in page.

Compare two lists: what your own system holds and what you last saw on the site. The gap between them is what you are blind to this morning. Guest messages sit in the extranet inbox; if you cannot read them, use the contact details you hold and keep messages factual: arrival time, address, what is ready.

Card details for a booking are handled inside the extranet, so a no-show cannot be charged the usual way. Write down what you could not do and when, so the day's accounts can be corrected later. Availability may keep selling while you cannot see it; decide who watches the phone and the inbox, and what the front desk should say to a guest who booked an hour ago.

Do not promise a guest something you cannot check. If a booking cannot be honored, tell the guest early and clearly, and confirm your own position with your adviser rather than relying on a rule of thumb. Once access returns, work the daily routine rather than the backlog; the routine itself is described in the extranet routine: what to check every morning, and the money side in how Booking.com commission is calculated and checked.

How do I write a one-page access record?#

One page, kept where the front office can find it, that says who holds which account, on which phone and mailbox, and what to do when a code does not arrive.

Record the property ID, the account username, the role mailbox that owns the account, the phone that receives codes, who holds the device with the Pulse app, the backup verification number, each user with their rights, and the date each item was last checked. Keep the password itself in a password manager, not on the page; the page tells you where to look, not what the secret is.

List every other system that depends on the same phone number, such as a channel manager, a payment provider or the hotel's own mailbox, so one lost SIM does not take three systems down. Review the record on every staff change and at least once a quarter, and test the full sign-in from a device at the desk. After an incident, add a short line: date, time, what failed, who was contacted, what changed.

What to do next#

Write the one-page access record today and test the full sign-in from the front desk phone, before the next busy morning. A lockout is rarely about a forgotten password: it is about whose phone the code reaches and who runs arrivals while access is down. If the failure arrives together with changes you did not make, stop treating it as a lockout and follow the takeover checklist instead.