Can you build a direct booking site on Hostfully? What its API lets you do

Can you build a direct booking site on Hostfully?

Yes, and all three steps are on Hostfully's own developer pages. A direct booking is one a guest makes on your own site, where you keep the whole rate instead of handing a platform a cut. If you have not settled on a property system yet, Choosing a PMS for a small hotel, inn or serviced apartment: what the API actually lets you build prices twelve of them at 8 to 25 rooms.

1. Your site creates the booking. Hostfully calls that record a lead, and its own documentation confirms an outside site can create one and that every later step happens on that same record.
2. It puts the lead on hold. Hostfully holds it for 24 hours by default, adjustable in your own settings, and a held room counts as taken on the calendar, so two people cannot buy the same last room while one of them is at the checkout.
3. Your site marks it booked once the card clears. Marking it booked turns the held inquiry into a real booking that behaves like any other reservation your staff can see.

What does the Hostfully API let your booking page do?

It reads your rates and your calendar, creates the booking, holds it, confirms it, and tells your site when something changes. An API is the set of doors a software company leaves open in its own system, so another program can read and change the same bookings your staff see on screen.

Every row checked on September 2026 against Hostfully's own pages: the getting-started guide, the pricing call, the calendar lookup and the Open API feature page.

Before your developer touches your real bookings, Hostfully makes them build and test the whole connection on a separate practice copy of the system first: its getting-started guide says "API development will always have to start on our sandbox." Only after that testing is done, and you ask Hostfully directly, does your developer get switched over to work with your live account and real guests. Schedule that waiting period near the start of your project. The key is a single one from your Agency Settings screen, sent with every request, and Hostfully's authentication page warns anyone building for several Hostfully customers at once not to use it, because it behaves differently for partners.

What breaks once real guests are booking?

The checkout itself works well. Where you lose money is what happens right after a booking changes, and before a guest ever gets as far as checkout.

The message does not say what changed, and is not sent twice

Hostfully has a feature called a webhook, which is its way of phoning your website the second something changes, instead of making your website ask over and over every few minutes. Its webhooks reference lets you subscribe to a new booking, a changed booking, a canceled booking and a new hold, among others, but guarantees only two pieces of information in that message: which account it happened on, and what kind of event it was. The property and the booking are optional, so your site is told something happened somewhere and has to ask what.

Two other problems show up here. Money moving on an existing booking, such as a guest paying off the rest of their balance, does not set anything off today. A customer request on Hostfully's feedback board has asked Hostfully to add that alert, but it is still just a request, not a built feature. Nothing proves a message actually came from Hostfully either: the same board asks for a signature, a header it could check, or a list of trusted addresses, and that too is still just a request, not a built feature. The workaround is to put a long secret code into the web address Hostfully sends the message to, since a forged message will not know that code.

Nothing on that reference, the getting-started guide or the help center promises a second attempt, and Hostfully itself confirmed it does not retry a failed delivery at all. So if your site is restarting at the wrong second, the message about a cancellation is gone and the room stays sold in your own records while the guest is at home.

The Hostfully column was checked on September 2026 against its webhooks reference; the Guesty column is what we found comparing the two for our own move. The wider comparison is in Hostfully vs Guesty: which one wins for a small operator.

MINT @Naschmarkt, the Vienna serviced-apartment business Maxine and I own, runs on Hostfully with our own checkout on top: 18 apartments in five apartment types. Processing the payment through our own checkout worked fine from day one. The trouble showed up after: a booking changed, the one message went out, and if our site was not listening at that second there was nothing to catch it later. Ekamoira, the agency I run, wrote a job that wakes every night, reads every booking for the next twelve months back out of Hostfully, corrects what our own records disagree with and tells us when it found a difference. The messages handle an ordinary day fine; the nightly job is what makes the calendar trustworthy.

Rooms of the same type get counted as one

Selling several rooms of the same kind costs you bookings here. Hostfully groups identical rooms together into what its own documentation calls a room type, and it prices and tracks availability for that whole group rather than for each physical room. It also says it may reassign which specific room fills a booking to keep your occupancy up. Hostfully confirmed its own under reporting is deliberate: no availability count, no per unit calendar. Guesty, the system we are moving to, hands your site a per day numeric allotment field instead.

Our own calendar did this to us: 5 of 30 nights looked bookable before the fix; 26 of 30 after, because the system had been reporting a whole apartment type as unavailable whenever just one physical unit in it was booked. No guest ever emails to complain about this. They just see a month that looks fully booked and reserve somewhere else instead. You can see the figures and their caveats on our results page, in the impact of the pooled availability fix we ran. There is a smaller problem here too. The pricing request prices a stay from a property and two dates but checks nothing about whether those dates are actually free, so a booking page that treats a price as proof of availability will quote a night you cannot sell.

Should you build on Hostfully?

If you are already on Hostfully, the answer is yes, and you do not need to migrate to anything else. The only reason to move systems for the API's sake is if identical rooms are already going missing from your own booking page. Hostfully publishes its prices: its pricing page puts Growth at $15 per property a month plus a platform fee, with a 1% payment gateway fee and a 0.85% direct booking fee on top, and Pro at $25 per property a month with both of those at nothing.

Both plan prices checked on September 2026 on Hostfully's own pricing page. Neither plan puts a number on the platform fee, so ask for yours.

If you are still not sure

We do the direct booking side for you, over whichever system you keep, and usually have it taking bookings inside three weeks. This makes the most sense for properties turning over roughly $350,000 a year in bookings and up, where the commission it saves you covers the cost of the work. Our own decision, in August 2026, was to keep Hostfully in maintenance only and move the calendar to Guesty only once we had run both systems side by side and confirmed Guesty got it right, a step we would not skip, and the booking path alone would not have moved us. Bring the plan you are on and the checkout you want. Book a call: twenty minutes, prepared for your own property.