Multi-Accounting for Travel Agencies: Managing OTA Partner Logins

GetAntik editorial team · October 7, 2026 · 10 min read

How travel agencies manage dozens of Booking.com, Airbnb and Expedia partner accounts safely with isolated browser profiles, proxies and 2FA.

An agency selling accommodation or tours through Booking.com, Airbnb and Expedia rarely manages just one property. A mid-sized management company typically has 15 to 80 listings on its books, each with its own partner dashboard on each platform. Multiply 40 properties by 3 platforms and you get 120 separate accounts, each with its own login, password, two-factor setup, and the owner's payout details.

Handling that volume from a single browser simply doesn't work: cookies from one account overwrite another, sessions drop, and logging into someone else's dashboard from the wrong IP and timezone makes the platform reasonably suspect account takeover. Here's how agencies structure this work through isolated profiles, what the OTAs themselves require, and where teams most often lose access.

Why one browser can't carry the load

Booking.com Extranet, Airbnb for Hosts, and Expedia Partner Central aren't just login forms — they're full systems that fingerprint sessions. These platforms track:

• IP and geolocation at login — expected to match the property's region, or at least the managing company's country;
• browser timezone and language — sharp mismatches against the listing's address trigger a review;
• session stability — frequent logins/logouts from different IPs during the day read as suspicious activity;
• cookies and local storage — if accounts get mixed inside one browser profile, the platform sees overlapping sessions and may demand re-verification of the owner's identity.

If an agency manager keeps 10 dashboards open in one Chrome window, switching between tabs, sooner or later a captcha pops up, or a document request, or a temporary lock — simply because the system sees chaotic logins into different business accounts from one browser fingerprint. To the platform, this looks like a single person trying to control other people's accounts without the owners' knowledge, even if the agency actually has a management contract in place.

What's allowed and what isn't

Booking.com, Airbnb and Expedia all have explicit policies on agency and property-management accounts:

• Booking.com permits managing multiple properties through Partner Hub and provides "manager," "owner," and "accountant" roles inside the dashboard itself — agencies register formally as a management company.
• Airbnb allows co-host access and professional property managers (Airbnb for Co-Hosts), but every listing must be tied to a real legal entity or individual owner, and the platform explicitly bans creating fake host profiles to get around listing limits.
• Expedia Partner Central requires separate registration for each property, with the owner's tax details on file.

In all three cases, the rules aren't against multi-accounting as such — they're against disguising the real owner of a property and against one individual pretending to be many independent hosts to inflate ratings or dodge moderation. The legitimate setup is an agency operating openly as a management company, with a contract and access granted by the property owner. Technically, that means each dashboard lives in its own isolated environment, with its own IP and fingerprint, while ownership and the contractual relationship stay transparent to the platform.

How the infrastructure is set up in practice

A practical setup for an agency running 40 properties across 3 platforms looks like this:

One profile per dashboard. In GetAntik, every OTA account gets a separate browser profile with a managed fingerprint: OS, browser version, screen, timezone, and language are pulled from the proxy's exit IP, so the environment matches the property's region or the agency's legal entity.

Proxy matched to the property's geography. If the listing is in Lisbon, logging into its Booking dashboard logically goes through a proxy with a Portuguese or nearby exit IP — that alone removes most of the initial suspicion. For a comparison of proxy types for this kind of work, see the breakdown on choosing the right proxy type for the task: OTA dashboards usually call for static residential or mobile IPs, not cheap datacenter ranges that platforms ban by subnet.

Cookies and sessions aren't touched by hand. Exporting and importing cookies in JSON or Netscape format lets you restore a dashboard's session without a re-login or captcha if the profile moves to another device. For new accounts it's worth doing a scheduled warm-up — logging in, checking a reservation, a couple of routine actions over several days — before putting any real load on the account, like changing prices or bulk-updating a calendar. The logic behind warm-up is covered in detail in the piece on preparing accounts before launching real activity — the principles are the same even though it discusses different platforms.

Two-factor codes live with the profile, not in a manager's head. Both Booking and Airbnb require 2FA to confirm payouts and bank detail changes. Storing codes in notes on a manager's phone is a risk: the person leaves, the phone gets lost, and payout access for that property is locked. GetAntik profiles include a 2FA key vault tied to a specific account, so the code generates right inside the browser next to the confirmation form.

Teams: who sees what

In an agency of 5–6 people, roles usually break down like this: a sales manager handles guest messaging, a revenue manager adjusts prices and availability, a finance person reconciles payouts, and the owner sees everything. Giving everyone identical full access to 120 dashboards is a direct path to mistakes — someone changes the price on the wrong property or approves a payout to the wrong account.

GetAntik handles this with team roles and limits — owner, admin, member, and finance roles see and can do exactly what's assigned to them, and property profiles get grouped (by city, say, or by manager). When someone goes on leave or hands off a portfolio of properties to a colleague, the profile is transferred inside the team without passwords getting forwarded over chat — the new person in charge simply gets access, and the previous one loses it. More on distributing roles and handing off profiles between team members is in the article on team roles and profile handoff.

Live view is also genuinely useful here: a team lead can step into a new manager's session and watch how they're drafting a reply to a guest or changing a rate in Extranet, without asking for a screen share over Zoom or making the person recount what they did afterward.

What it costs, and when the extra setup pays off

For an agency running 5–10 properties, a couple of isolated profiles and a basic proxy set-up is enough — the Starter plan with 20 profiles at $5 a month covers that with room to spare. Once the portfolio grows to fifty-odd properties across several platforms, you're counting in the hundreds of profiles: the Base plan at 100 profiles for $44, or Team at 300 for $79, covers most mid-sized management companies. Large operators with several hundred properties and a staff of 15+ usually move to Enterprise at 1000 profiles for $149 — the per-profile cost there is lower than on Base, for a much larger volume.

It's worth calculating this not just in profiles but in proxies and manager time too — the methodology is laid out in the article on team budget for profiles and infrastructure. For a travel agency, the biggest cost line isn't the profiles themselves but proxies tied to the property's region, especially if the portfolio is spread across different countries.

Common mistakes

One IP for every dashboard in a given city. If 8 properties in Barcelona are all run through the same static IP, Booking sees a cluster of accounts with identical network exit points and starts demanding extra verification across the board. Use different proxy subnets even within one city, especially for neighboring properties under the same owner.

Timezone mismatch between the profile and the property's address. If a profile for a listing in Thailand shows New York time and a default English keyboard layout, it's not critical the first time, but with regular sessions the mismatch accumulates and becomes one more risk factor alongside others. Why small inconsistencies add up into a bigger problem is covered in the article on fingerprint consistency.

One shared phone number for 2FA across dozens of accounts. It's convenient to set up a single number and receive all the codes there, but when the employee physically holding that phone changes jobs, the whole payout chain grinds to a halt. A key vault tied to the profile removes that dependency on a specific device.

Sending a password over chat when a manager goes on leave or leaves the company. Beyond the leak risk, this creates a situation where a former employee can technically still log into a client's dashboard months later. A clean offboarding procedure and profile handoff removes that risk — it's described in detail in the piece on closing off access when an employee leaves.

Mixing test and live accounts in one profile. Before launching a new listing, agencies often test descriptions, prices, and photos on a temporary or test account. If that testing happens in the same browser profile as the live dashboard, cookies get mixed, and the next login to the live account shows up as atypical activity to the platform.

Launch checklist for a new property

1. Create a separate profile with a fingerprint matching the country of the agency's legal entity or the property owner.
2. Attach a proxy with an exit IP in the property's region (or in the managing company's country, if that's what the contract specifies).
3. Set up 2FA directly in the profile's vault, not on a manager's personal phone.
4. Warm up the account for a few days with ordinary activity before launching bulk price or calendar changes.
5. Assign a responsible manager with the right role, and restrict the finance person to payout viewing only if that's all they need.
6. File the profile into a group structure by city or by client, so the next person handling the handoff can find the right dashboard quickly.

If a property portfolio is growing faster than the process keeping up with it, it's worth planning the group and tag structure for profiles early — otherwise 150 dashboards turn into an unstructured list within six months. General principles for organizing a large profile pool are covered in the article on organizing hundreds of profiles without drowning in chaos.

A good place to start is downloading the app and setting up the first few profiles for a pilot batch of properties — the free plan includes 3 profiles, enough to test the proxy and 2FA vault setup before scaling it across the full portfolio. More on distributing roles and limits for a team is on the team features page.

FAQ

Can dashboards for several properties be run from the same physical office and the same ISP? Yes, as long as each dashboard opens in an isolated profile with its own proxy and fingerprint — the platform sees separate sessions, not one browser jumping between accounts. Running everything over shared office Wi-Fi without individual proxies is risky, especially on Airbnb, where a cluster of accounts from one IP gets flagged for review quickly.

Does this break Booking.com's or Airbnb's rules? No, as long as the agency operates as an official manager with the property owner's knowledge and under contract, provides real information, and doesn't create fake host profiles. Both platforms explicitly accommodate management companies and multi-property operators in their partner programs.

Does the proxy need to match the property's country specifically, or is a proxy matching the agency's country enough? It depends on the platform's requirements and the contract with the owner: if the dashboard is formally registered under the agency's legal entity, a proxy matching the entity's registration country can work. If the account is registered under the property owner, an IP in the property's country is the safer choice — it reduces how often verification gets requested.

What if the platform still asks for identity verification when logging in from a new profile? That's a normal one-time step the first time you access a new environment — it goes through standard document verification, the same thing an ordinary user would face logging in from a new device. Once verified, the session gets tied to that profile, and repeat requests generally don't come up as long as the profile's IP and fingerprint stay stable.

multi-accountingtravel agenciesotabooking.comairbnb