Reconnecting a Channel After a Password or Key Change

Changing a channel password does not cut the connection at that moment. It cuts it at the next refresh, which is usually the worst possible time.

Last updated: October 14, 2026

A password change on a channel looks like a small piece of housekeeping. You rotate a credential, you save it, and nothing appears to move. The listing page still loads. The connection doesn't fail while you're watching it. It fails at the next refresh, often in the middle of the night, and that delay is the whole problem.

Key Takeaways

• A credential change doesn't break the link on the spot. The channel keeps its last known state until the next refresh, so the break lands later and quietly.
• Reconnect from your own side. Repairing the link from your own record keeps the listing you already have instead of spawning a second copy of it.
• Confirm both ends before you leave. Read the unit on your side and the matching unit on the channel while you're still in the flow.
• Watch the source status, not the page. A page that loads proves nothing; the calendar's source status is what shows the link is live.
• Rotate one credential at a time. Two changes in one sitting leave you unable to tell which one broke the link.

Why the disconnect is delayed, not instant

A channel doesn't check your password every time someone opens your listing. It holds a working session and re-verifies that session on a schedule. Change the password between two checks and nothing objects yet. The channel is still acting on the permission it last saw.

That gap is what makes the whole thing confusing. You change the password, you confirm it saves, and every page you open behaves normally. Then the next refresh arrives. The session no longer matches, the sync stops, and the first symptom isn't a login prompt. It's a calendar that has quietly stopped changing.

The timing is the cruel part. Refreshes tend to run on the platform's clock, not yours. A change you make at four in the afternoon can sit fine all evening and fail at three in the morning. If a guest books inside that window, the booking lands on one side and not the other. The two calendars drift apart before you've looked at either.

There's a second reason this catches hosts off guard. A password change feels like a security chore, about as related to your inventory as changing a light bulb. Nothing in the act warns you that a listing's link leans on it. So the instinct is to save, close the tab, and move to the next task.

None of that makes the cleanup hard. It just makes it easier to do at the moment of the change than to reconstruct once a night has already slipped.

Reconnecting without duplicating a listing

When the calendar stops updating, the fastest-looking fix is to add the channel again as a fresh connection. That's the one to avoid. Most channels will accept a second connection to the same unit, and two connections to one door is how the same nights get sold twice.

The safer route is to repair the link you already have. Keep the record on your side, re-establish the connection to that record, and leave the existing listing in place. A repaired link inherits the history, the reviews and the rate plan the original already carried.

This matters more once you count how many links one unit holds. A direct connection reaches four channels, and each of them keeps its own copy of your listing: Airbnb, Booking.com, Agoda and Trip.com. That's four records and four sessions, so a single rotation can leave one of them stale while the others look fine.

Before you touch anything, check what's actually on the channel. If your listing is still published and only the sync has stalled, you want a reconnect, not a re-creation. If the listing has vanished, that's a different problem, and re-adding it belongs at the end of the list, not the top.

One habit keeps the credentials themselves contained. LOCALSBNB stores connection credentials locally rather than pooling them in a shared place, masks guest names and contact details automatically, and grants access by domain. That layer is what matters when a password rotates: you repair a link, and the guest data behind it stays where it belongs.

What to confirm on the channel side

Reconnecting from your side is half the job. The other half happens on the channel, and it's mostly reading rather than changing.

Start with the listing itself. Confirm the unit is still published, still points at the same address, and still carries the rate plan you expect. A reconnect that fixes the sync but leaves a stale price on the channel trades one quiet problem for another.

Then check the linkage the channel keeps on its own record. You're looking for the same unit, not a copy of it. If a second record exists for the same door, you'll want to sort that out before you reconnect, because reconnecting a duplicate just makes the duplicate live.

Next, look at the calendar mapping. The nights you've blocked on your side should read as blocked on the channel, and the nights you've opened should read as open. Read that mapping before you trust the reconnect, not after a guest books a night you thought was closed.

Finally, confirm the direction of the data. Not every field flows both ways, and some channels hold the master copy of a given field. If a rate or a restriction looks right on one side and wrong on the other, work out which side owns it before you start editing.

Two things are worth writing down while you're in there: the date you reconnected, and the listing reference the channel uses for that unit. A short written trail turns the next break into a two-minute job instead of an investigation.

Proving the link is live again

A page that loads isn't proof. The listing page was probably loading fine the entire time the sync was broken, which is exactly why the break was easy to miss. To prove the link, you want a signal that depends on the connection working, not on the page rendering.

The clearest signal is the source status on your calendar. LOCALSBNB's calendar shows each connected channel's source rate and source status, so you can read whether the channel you just repaired is reporting again. That's a connection fact, not a page fact, and the difference is the whole point.

Then run a small, reversible test. Change one rate by a small amount, or block one far-off night, and read it back on both sides. If the change crosses over, the link is doing its job. If it doesn't, you've found the problem while it's still cheap.

Give the test a little time before you call it. A change that hasn't crossed over yet and a change that will never cross over look identical for the first few minutes. Pick a marker you can check later, and check it later.

Once the link is confirmed, clear the duplicates you may have created in the panic. A second connection you added while troubleshooting will keep selling nights until you remove it. Sweep the channel list, keep the repaired link, and retire the spare.

If you'd rather read the connections side by side while you work through this, localsbnb.com puts the channels and their source status on one screen, so you can see which link is reporting and which one has gone quiet.

FAQ

Does changing the password break the connection immediately?

No. The channel keeps its last known state until the next refresh, so the break arrives later. That gap is why the failure so often shows up overnight, when nobody is watching the calendar.

Should I add the channel again as a new connection?

No, and this is the step that causes most of the damage. Reconnect the listing you already have. Adding a second connection to the same unit is how the same nights end up sold twice.

How do I know the link is actually working again?

Read the source status on your calendar rather than the listing page. Then change one small thing, like a single rate or one distant night, and confirm it crosses over to the channel.

A credential rotation isn't a repair job if you handle it in the same sitting. Repair the link, read the source status, run one small test, and clear any spare connection you made along the way. If four links are easier to compare than to remember, localsbnb.com keeps them together on a single screen.

---

This is general advice for hosts, and it isn't legal, tax or insurance advice. Rules and platform terms vary by place and change over time; check the current requirements of your local authority and the current terms of each platform you use.