This isn’t an easy thing to build in Bubble (I say this as someone who has built most, if not all, of the components that such a system requires) and it’s actually not an easy thing to build on any platform. (And you certainly can’t build it “without code”. )
tl;dr department: Tell your b&b owner to look into vacation rental channel management solutions like Lodgable (https://lodgable.com/) – it’s free. There are other solutions, of course, but this is a good starting place. And just know that, unfortunately, there is no real way for you to add additional value here, @f.dannunzio92. (So, pick another project.)
Slightly longer answer:
As others have pointed out, there are no publicly-accessible APIs for the various short-term rental (STR) online travel agencies (OTAs) like Airbnb, Booking, and VRBO. For quite a long time now, those APIs have been closed except to partners (and, no, you are not a viable partner). And, unlike in many other technology sectors, in travel and tourism, the OTAs do not expose handy modern things like webhooks or APIs as they have no incentive to open their platforms. They are essentially walled gardens.
It’s actually a wonder that there are any channel-management platforms at all (and they may be dying out or dwindling) as the OTAs have no incentive to help independent STR/vacation rental operators and small agencies manage multi-channel operations. Each would much rather have a given property or small agency use its platform exclusively. And they certainly don’t want to help enable direct booking business, right? (Because their whole business model is built on commissions.)
The only reason that these platforms have APIs at all anymore is to increase their share with larger regional or local STR agencies who own and/or manage a significant number of rental properties. These agencies operate their own local/regional direct booking sites and at least have some power to do direct booking at scale, so they cannot be ignored. Those agencies need ways to make their hundreds or thousands of listings available via both their direct sites and as listings on the various OTAs, so technology solutions are needed.
This is the only reason, and the only type of organization, that can (I should say could, past tense, because all such agencies are already partnered with the various platforms) become a “partner” with one of the OTAs.
There is the rare non-competitive technology player that might qualify to become a partner, but these have to reach significant scale before they’ll be considered. (I’m thinking of things like dynamic pricing systems, labor management/scheduling systems, etc.)
Beyond that basic problem, here are some of the technical challenges to be aware of:
Since you don’t have API or webhook type access to get notified of new reservations on the various platforms, you could take a pull/polling approach (this is inefficient and the wrong way to do it, but it could be done).
The various platforms do expose ical feeds of their properties’ calendars, so an individual owner (or indeed anyone) could potentially understand booking activity by regularly pinging those .ics endpoints, consuming the data, and looking for changes.
While you could run that code on Bubble’s backend as a server-side action (SSA) plugin, Bubble’s pricing structure (the fact that it marks up SSA execution by a usurious amount) makes this untenable. So you’d run that code in some other function-as-a-service provider. What that code would so is, in response to a ping from Bubble’s API connector is fetch the ical data from the .ics URL in question, parse the data and return it to Bubble in a format that the API Connector can reasonably consume.
(Note that I operate a vacation-rental oriented site and need to consume ical data to display availability calendar information, so I know what I’m talking about. I run my ical fetch and parsing code in Google Cloud. Most months this costs absolutely nothing, though this does consume WUs on the Bubble side because each outbound API Connector call costs WU and there are also ingress charges for the incoming data.)
Again, since you don’t know when something has changed in any of those calendars, you’d have to ping them on some regular basis to understand if something had changed. So this wouldn’t be real-time. (Also, this gets expensive quickly in Bubble. It’s basically a non-starter.)
Now, some of the channel management solutions do provide (or at least used to provide) webhooks to ping external systems about changes in the property listings that they manage (Lodgable at least used to enable this). So that’s potentially one route. But it’s likely that the channel management solution already has all the other features that your client needs, so it’s unlikely you’d really need to build anything else.
Presumably you would also need to present a unified calendar view of the property’s (or properties’) availability and you won’t be shocked to learn that there aren’t many good solutions for that. (My Calendar Grid Pro plugin is designed specifically for this use case of displaying some sort of nightly [or daily] availability for a single something, but I never finished building it out to support multiple somethings in a unified view. Though it’s also a very handy timezone-aware date range picker, which is something else you would most likely need.)
Though you can consume availability information via ical, you can’t communicate something like a reservation change or cancellation to an OTA platform via iCal. (And again, you don’t have any APIs for doing so except perhaps the API of the channel management application you integrate to… But those platforms already do this task.)
The one thing you could (I’m talking theoretically here, you wouldn’t actually want to do this in Bubble) is consolidate the various ical feeds that your client needs to monitor, publish that as an ical feed and then use that feed as the “master” ical feed for the various platforms they work with.
But there are technical challenges (and again cost considerations) in doing this in Bubble. While it’s possible to spit an ics file out of a backend workflow, the URL to that endpoint will not “look like” a static ics file and so won’t work with all ical-consuming systems out there. Additionally, the cost of running that workflow will be ridiculous (and keep in mind that you have no control over how when and how often that endpoint might be hit).
You might imagine you could go the third-party FAAS route again and, should some endpoint URL be hit, you ping an external service that generates and returns a .ics file, but there are issues with this again.
You might then think, well, OK whenever there’s a change, I’ll create a new .ics file and store it so that it can be accessed. But there’s no simple way to do this in Bubble. (You’ll wind up with a file in some Amazon bucket, the URL to which constantly changes. So you can’t have that at all.)
tl;dr department 2: This is a buy thing, not a build thing because:
- You can’t get access to OTA APIs.
- Bubble just isn’t architected to support this sort of use case well.
- You can’t really support this use case at all without a channel management solution partner that your client will have to use.
- Anything you could build in Bubble likely already is a good-enough feature of that channel management system, so there’s nothing you need to build.
- It’s not even really a “buy” decision as there are low-cost and even free channel management solutions for independent STR/VR operators.
But, I’ve spent a lot of time around these issues and I like to occasionally share my experience here. You can be forgiven for thinking, “This seems like something that would be easy to build in Bubble.” But it is certainly not one of those things.
