Connecting Two Channels: The First Fortnight of Checks

A connection looks finished the moment the status turns green. The fortnight after that is where you find out whether it actually is.

Last updated: October 1, 2026

A channel turns green when the link is live. It doesn't turn green because your dates, rates and blocks are landing correctly on the other side, and nothing tells you the difference. That's what the fortnight after connection is for. Four checks in the first 48 hours, one deliberate change every two weeks, and you'll know whether your second channel is working or merely connected.

Key Takeaways

• Green means connected, not verified. The status reports a live link, and says nothing about the data travelling through it.
• The first 48 hours carry the most risk. Mistakes are cheapest to find before a real booking tests them for you.
• Push one deliberate change every fortnight. A rhythm finds drift that a one-off check never will.
• Fix disagreements at the source. Correct the side that owns the data, then let the other side catch up.
• Keep a short dated log. Four lines and a date are enough to tell a repeat problem from a new one.

What the connection screen confirms, and what it can't

A direct connection is a live link between your calendar and one of the four channels you can sell on: Airbnb, Booking.com, Agoda and Trip.com. Setting one up means the two systems agree on credentials and on which of your listings corresponds to which channel listing. That agreement is what the status light reports. It's a handshake, not a result.

Read green as one fact, not three. It confirms that your credentials were accepted, that the link is open, and that the channel is willing to receive data from you. What it can't confirm is that the data arriving is the data you meant. A listing mapped to the wrong counterpart still goes green. A weekly rate read as a nightly one still goes green. A restriction that never carried across still goes green.

That gap exists because these are two separate systems with two separate ideas about what a change means. They catch up rather than move in the same instant, and the direction matters: some information flows from you to the channel, some flows back. Green certifies that the pipe is open. It says nothing about what's inside it.

This is where your own calendar earns its place. It shows the source price and the source status for each connected channel, so you can put what a channel is currently offering next to what you set. That single column is the whole verification habit in miniature: change something here, then look at what the other side believes it has.

One more thing worth settling early. A connection doesn't remove the need to look. It moves the looking from four logins to one screen, which is a real saving and not the same thing as handing over responsibility.

Four checks for the first 48 hours

The first two days carry most of the risk, because that's when every mistake is still cheap to fix. None of these checks takes long, and together they cover the failure modes that a green light hides.

Count the bookable nights. Take a month you know well and count the open nights on your calendar, then count them on the channel. If the two numbers differ, you've found a mapping or restriction problem before a guest finds it. Do the same for the shortest open window in the month, since a single missing night in the middle is easier to spot than a total.

Send one rate change and go looking for it. Change one rate for one clearly identified period, then check what the channel is showing for those nights. Pick something you can recognise instantly, like a rate you'd never otherwise use. If it arrives, the rate pipe works. If it doesn't, you've learned that in the first hour rather than the first busy weekend.

Confirm the mapping, listing by listing. Each listing on your side should point at exactly one listing on the channel, and the pairing should make sense to a person reading it. Check the title and the capacity, not just the identifier. A cross-mapped pair is the kind of error that produces bookings on a unit you didn't intend to sell.

Block one night, then release it. A block tests the direction the money doesn't travel. Close one night on your calendar, confirm it closes on the channel, then open it again and confirm it reopens. If it sticks on the channel side, you'll find out now; if it stuck during your busiest week, you'd find out from a guest.

Write the four results down with the date you ran them. That page becomes the baseline you compare the next fortnight against, and it takes four lines.

The fortnightly rhythm: rates, blocks and one live change

A one-off check tells you the connection worked on the day you looked. A fortnightly rhythm tells you whether it still does.

The habit is small. Every two weeks, pick one change, make it on your side, and confirm it on the other side. Rotate what you test rather than repeating the same one, because each type of change exercises a different part of the link. One fortnight, a rate. The next, a block. The next, a capacity or minimum-stay detail that a guest would notice.

Rates deserve the most attention, since they change more often than anything else and a stale rate is the quietest possible problem. A blocked night shows up as a lost booking. A stale rate just sells at yesterday's number, and nobody complains about a price that's too low. Checking the source price and source status per channel on one screen is the fastest version of this habit, and it's the one that survives a busy month.

Blocks and releases come second. Whenever you close dates by hand, treat the release as the part worth confirming, because that's the direction guests never help you test. An unblocked night that stays blocked on a channel is invisible until someone asks why the room is unavailable in peak season.

Then add one live change — something you'd genuinely make anyway. This is the difference between testing a system and using it. A real change on a real booking window, verified in the ordinary course of work, tells you more than a synthetic test that you'll never repeat.

Keep the rhythm on the calendar rather than in your head. Two weeks is close enough that a problem can't grow into a pattern, and far enough apart that you don't spend your week on it.

What to do the first time the two calendars disagree

It'll happen. One side will hold a booking the other doesn't, or a night will be open on one screen and closed on the other. What matters is the order you do things in, not the alarm you feel.

Stop taking new bookings for the dates in question before you investigate. This sounds drastic and it isn't. It costs you nothing but a few minutes, while a second booking on the same nights costs you an apology, a refund and possibly a guest you'll never host again.

Then work out which side owns the truth. A booking that exists on a channel owns its nights, whatever your calendar thinks. A block you placed yourself owns the dates you closed. Practically, that means asking where the information was created: the platform that took the booking is the source of that booking, and your calendar is the source of the blocks you set.

Fix the problem at the source, not in the copy. If a night shouldn't be open, open and close it again on your side and let the channel follow. Editing the channel directly often works for a day and then gets overwritten by the next update from your system, which is how a one-off fix becomes a recurring mystery.

Then write down what happened: the date, the dates affected, which side was right, and what you changed. If the same disagreement returns, that note tells you whether the cause is the mapping, the restriction or something you haven't touched yet. Nothing here guarantees a calendar with no clashes — no setup can promise that — but it does mean a clash stays a single incident instead of becoming your normal.

There's one place where the two views sit side by side instead of in separate tabs. localsbnb.com keeps every connected channel on the same calendar, which is what turns the fortnightly pass into a routine rather than a project.

FAQ

Should I connect the second channel before or after I check the first?

After. Get one channel verified through the first 48 hours and one fortnightly pass, so you know what correct looks like. When the second channel disagrees, you'll be comparing it against a baseline you trust instead of guessing.

How soon should the two calendars match?

They catch up rather than move together, so expect a short gap between a change here and its effect there rather than an instant update. What matters isn't the exact interval; it's whether a change you make reliably arrives, and whether you can see the result on one screen.

A guest booked nights my calendar shows as open. What now?

Treat the booking as the truth and the calendar as the copy. Close the dates, confirm with the guest, then look at why the night stayed open: an unmapped listing, a restriction that never carried, or a block you released by hand. Record which one it was.

The fortnight after connection is unglamorous work, and it's the cheapest insurance you'll buy this year. Four checks, one change every two weeks, and a log you actually keep. localsbnb.com puts Airbnb, Booking.com, Agoda and Trip.com on one calendar with each channel's source price and source status visible side by side, so the verification habit takes a minute instead of an evening.

---

This article is general guidance for hosts rather than technical advice. How each channel receives and reports availability, rates and restrictions differs between platforms and changes over time; check the current terms and documentation of each platform you sell on.