Calendar & sync
Connect every booking platform you sell on to i3nb instead of to each other — then choose, per connection, what you accept coming in and what you publish going out.
If you have ever pasted one platform's calendar export URL into another, you made a decision you probably did not mean to make.
A platform's iCal feed does not tell the next platform what is happening on a given night. It says the night is closed, and nothing else. A confirmed guest reservation, the turnover time you asked that platform to leave between stays, every night past the end of your booking window there, and a Tuesday you blocked by hand for a plumber all leave as the same event, carrying the same two words: not available.
The receiving platform cannot tell them apart, because there is nothing there to tell apart. So all four become unbookable nights. That calendar is now enforcing the first platform's turnover buffer and booking horizon — settings you chose there, for reasons specific to that platform, now silently governing a channel with different guests, a different lead time and a different cancellation policy.
Reverse the arrow and the same thing happens in the other direction. Point them at each other and you get both problems at once, plus a loop where each platform re-publishes the other's blocks back as its own.
| What it really is | What the platform publishes | What the next one does with it |
|---|---|---|
| A confirmed guest reservation | not available | Closes the night |
| Preparation time between stays | not available | Closes the night |
| Anything past your booking window there | not available | Closes the night |
| A date you blocked yourself | not available | Closes the night |
Four different things. One indistinguishable output. That is the whole problem, and it is why "just connect the calendars" quietly costs multi-channel hosts real nights every year.
One platform feeds another. One is master, the other obeys — and you do not get to choose which. Every settings artefact from the master becomes a closed night on the follower. Adding a third channel makes it worse, not better.
Every channel talks to i3nb, and i3nb talks to every channel. No channel ever reads another channel's feed. i3nb holds the calendar that is actually true, and builds each channel a feed from your rules.
Most platforms let you leave a gap before and after each stay for turnover, commonly one to seven nights. Those nights arrive looking identical to any other closed date, so i3nb identifies them by position: a blocked run that touches a reservation and lasts seven nights or less. Anything longer is treated as an ordinary not-available date, so a long block sitting next to a booking is never mistaken for turnover time.
The dates beyond your availability window on that platform, and any dates you blocked by hand there. Turn this off and that platform stops closing nights in i3nb — which is how you keep a shorter booking window on one channel than another. Keep one platform's own window at six months because its cancellation terms make an eighteen-month booking worth very little to you, decline those dates here, and your other channels stay open to twenty-four months from the same calendar.
Each connection can be included in, or held out of, the feeds i3nb publishes to your other platforms. Leave it on to use i3nb as the source of truth: every platform then reads one calendar built from your rules, instead of reading each other.
A real booking on any connected platform always closes those nights everywhere. There is no switch for that, deliberately: it is the one thing that must never depend on a setting being right.
This is availability, not pricing. The iCal standard every platform speaks carries dates and nothing else — there is no field in it for a nightly rate, a minimum stay or a discount. So today your rates stay where you set them, on each platform, and i3nb does not change them.
Managing rates from one place needs a platform's API, not its calendar file. We can do that wherever a platform grants i3 New Beds API access, and we build it as those partnerships open.
It is worth being straight about why that is a partnership question rather than an engineering one. Many platforms gate API access to software like ours, because a tool that makes it easy to price and manage several channels side by side makes it easy to leave any one of them. The permission model to do this well already exists on their side; what is missing is the permission. We would rather say that plainly than imply a capability we cannot deliver on a platform that has not opened the door.
Live today. i3nb runs the hub: import the iCal feed from every booking platform you sell on — up to two per platform and four custom feeds per listing — merge them with the bookings taken on your own site and the dates you block by hand, and give each connection its own outbound feed with that channel's own events filtered out so nothing echoes. Each connection is tracked independently, with its own last-sync time, last error, and a breaker that disables one failing feed instead of letting an empty calendar wipe out real bookings. The per-connection rules above are in place.
Being rolled out. The block classifier that separates preparation time from every other closed date starts in observation mode on a new connection, so you can see what it found on your own calendars before any of it changes what is bookable.
We would rather tell you exactly which half is finished than let you find out later.
One villa, on two booking platforms. The first has cancellation terms loose enough that a booking eighteen months out is close to worthless to you, so you keep its window at six months. Guests on the second book further ahead and cancel less, so you want twenty-four months there.
Chained together, this is not merely awkward — it is impossible. The first platform exports months seven through twenty-four as blocked dates. The second imports them. That calendar is now closed for the eighteen months you were specifically trying to sell, and nothing anywhere tells you that is why.
Through i3nb you decline the first platform's not-available dates and keep its turnover days. The six-month horizon stays where you set it — on that platform — and never reaches the second, which stays open to twenty-four months from the same calendar. A booking on either channel closes the night on both at the next sync, because a booking is a booking and i3nb knows the difference between that and a settings artefact.
Hosts on two or more channels. The moment there is a second channel, someone has to decide which one is in charge. It should be you.
Property managers. The same rule set across a portfolio, applied per channel per listing, instead of one master calendar per property maintained by hand.
Anyone selling from their own website. A booking taken on your own site is the one reservation no platform knows about. It has to close the night everywhere, immediately, or it is a double-booking waiting to happen.
No. Each platform still owns its own bookings and you still manage the listing there. What changes is what that platform reads from and writes to: i3nb, instead of another booking platform.
iCal is pull-based, so each platform decides how often it fetches. i3nb regenerates your feeds the moment a reservation lands and serves a versioned ETag, so a frequent poller gets a cheap "nothing changed" answer instead of being rate-limited — but the real limit is the platform's own polling interval, typically minutes to a couple of hours. No iCal-based system is instant in either direction, and anyone telling you otherwise is not describing iCal.
Yes, and those blocks are part of what i3nb publishes. Close a week for a renovation once, in i3nb, and every connected channel sees it closed.
Connections are independent. i3nb records the last successful sync and the last error for each feed separately, and after repeated failures it disables that one connection rather than letting a broken or briefly empty calendar erase real bookings. The other channels keep syncing.
No. Each channel feed excludes the events that arrived on that connection, so a platform never sees its own calendar reflected back at it. That loop is the single most common way DIY iCal chains corrupt themselves.
No. Create a free account, add your property, connect your feeds. Listing publicly on i3nb is a separate, optional thing.
Free to start. Connect your channels in a few minutes and stop letting the strictest one set the rules for the rest.
