Hostaway keeps its whole public API in one reference, at api.hostaway.com/documentation. Everything a direct booking site needs is in there: listings, availability calendars, reservations, guest messaging, money, and the messages Hostaway sends your site when a booking changes. A developer building the checkout will spend almost all of their time on reservations and on those messages. You make the key yourself, under Settings and then Hostaway API, and trade it with your account ID for an access token, the pass your site sends with every request. Hostaway says that token lasts 24 months. Your checkout creates a real reservation, and if you switch card validation on, the same request charges the card. Hostaway's reference says that "if the charge fails the reservation will be deleted and you get a response with error". The reference never describes a way to keep the dates off sale while a guest is still typing a card number.
Getting a key, and the request limits you work under
Nobody at Hostaway has to approve you before you can have the key, and Hostaway says outright that building your own site is a supported thing to do. Its Booking Engine Fee article puts it plainly: "You can use any booking website with Hostaway or even build your own through our integrations."
Hostaway's authentication section gives that access token a life of 24 months, long enough that your code stores it once and rarely has to ask for another, where plenty of other systems hand out tokens that expire within a day. Above it sit the request ceilings: 200 requests every 10 seconds per account, and another 200 per 10 seconds per IP address, with the call that creates a reservation counted against the account figure. A search page that prices a dozen units across a month of dates will meet that ceiling long before a checkout does. Pull a range of calendar days once and price from what you already hold, rather than asking Hostaway again for every unit and every date on the screen.
Hostaway offers no practice account to build against and no ready made code to start from, so your first reservation gets written into a live account with a real card. The independent API Report Card grades the API D overall as of September 2026. It scores access and coverage well, and marks down the documentation and the developer experience for those two absences, and the stability for an earlier retirement of Hostaway's webhooks that made integrators rewrite working code.
| What you want to do | What Hostaway gives you |
|---|---|
| Take a booking from your own checkout | A reservation your own call creates, charged in the same request if you ask for card validation |
| Keep the unit off sale while the card clears | Not documented. The only hold is a security deposit, taken days before arrival |
| Hear about a change without asking | Webhooks, retried 3 times, then an email alert |
| Get access | A key you create in the account and swap for a token good for 24 months |
| Read the reference | api.hostaway.com/documentation, one page covering the whole API |
Every row above checked on September 2026 against Hostaway's own documentation.
How the checkout takes the money
Your developer adds validatePaymentMethod=1 to the reservation request, together with the guest's card details, and Hostaway makes the booking and takes the payment inside that one request. One piece of setup has to exist first: a guest auto payment rule carrying an auto charge on the reservation event, timed to run the moment the reservation is made. When the bank declines, Hostaway removes the reservation and hands back an error, and your page is left with one job, telling the guest what happened and asking for another card.
Take the money in your own payment step and the booking stays exactly where it is when the card is refused, so canceling it becomes your code's job. Nothing in Hostaway expires an unpaid reservation by itself. If anything goes wrong between the reservation request and the charge, that night is sold to nobody until somebody clears it.
On either route, Hostaway sets no dates aside while a guest is paying. The one hold its guest payments module documents is a security deposit pre-authorization. Hostaway schedules that one a few days before arrival and releases it after the guest leaves, so it is not available at the moment somebody is on your checkout page. The reservation statuses that block the dates while a guest finishes something are marked Airbnb only. A field named pendingExpireDate does appear in the reservation's list of fields, and it holds a date and a time, but Hostaway leaves its description blank and never says anywhere what fills it in or what it does. A checkout cannot depend on it, and we have not run a test on a live account that would tell you otherwise.
If you want the dates held while a card clears, your developer has to build that part outside Hostaway. Stripe's manual capture keeps an authorization alive for around 7 days on an online payment, which is room enough to authorize first, create the reservation second, and take the money when both have gone through. Guesty solves the same problem a third way: its checkout starts from a reservation quote that guarantees the price for 24 hours while saying nothing about the dates.
How Hostaway tells your site a booking changed
Hostaway sends a message to a web address you register with it whenever a reservation is created, changed or canceled. Three documented behaviors decide how far you can trust that channel.
The retry budget is small. A failed delivery is retried 3 times, after which Hostaway stops and emails the failure to an address you nominate or to the account's primary address. Hostaway is moving these messages onto a newer system it calls unified webhooks, and under its rules only a failure that looks temporary earns those three retries: a dropped connection, a crash on your server, or your server replying that it is being asked too often. All three attempts happen inside roughly an hour. If your server instead replies that the message itself was wrong or not allowed, Hostaway treats that as permanent and never sends it again, so a handler that rejects a message it cannot parse has thrown that notice away for good. Hostaway also wants an acknowledgement within 20 seconds, which rules out doing the work first and replying afterward.
If deliveries to that address keep failing for 5 consecutive days, Hostaway switches it off. A security certificate that runs out on a Friday evening can burn those five days before anyone is back at a desk, and once Hostaway has switched the address off, no further messages arrive until somebody notices and turns it on again.
Two of the older event types are being replaced. In the same reference, the legacy reservation and conversation message webhooks carry a warning that the unified ones will take over from them, so a checkout built on the old events now will have to be rebuilt later.
Read your reservations back from Hostaway on a schedule and compare them against what your own database believes. If a cancellation message never arrives, your own site goes on showing that night as sold while Hostaway shows it as free, and comparing the two is the only thing that catches it.
When the property system charges the card instead of you
Any property system that can charge a card while it makes a booking can charge it on an account you did not expect. We met that on our own. MINT @Naschmarkt in Vienna is ours, 18 serviced apartments in five apartment types, and we take deposits on our own Stripe account. A booking arrived on a rate that cancels free, and the money was collected about 7 seconds later, which nobody on our side had asked for. On the transaction sat a platform processing fee equal to 1% of the charge, a line that only appears when the money runs through the property system's own Stripe connection rather than the property's.
On any system that can charge a card while it makes the reservation, check which Stripe account the money actually landed in, and whether a fee nobody agreed to is riding on it. Hostaway connects to your own Stripe account, or to Braintree, though not to both on one account, and it adds Stripe's processing fee to the reservation using what Stripe reports back.
Should you build it, and what does it cost?
Hostaway will host a booking website for you and it costs nothing to switch on. The Booking Website overview says the site is available at no cost to every Hostaway user. Hostaway instead takes a percentage of every reservation booked through that site, set by where the listing is.
| Where the listing is | What Hostaway takes on a Booking Website reservation |
|---|---|
| United States, paid through Stripe | 1.8% of the base rate and fees, taxes excluded |
| Canada, the UK, Europe and the rest of the world | 0.5%, charged as a Host Processing Fee |
| Both at once | Never. A listing carries one of the two |
Every row above checked on September 2026 against Hostaway's own pages.
Card processing sits on top of that and remains your own arrangement. In the US Stripe's published rate is 2.9% plus 30 cents on a domestic card.
Hostaway's own subscription price is published nowhere. Its pricing page opens a three step form that begins by asking how many listings you manage, and quotes no rate at any size, so the software bill starts with a sales call.
At 1.8% in the US and 0.5% everywhere else, a custom build will not pay for itself out of the fee. An owner selling mostly through Booking.com and Airbnb, with nobody on call to fix a broken checkout, should switch the hosted site on this month and pay the percentage. A build is worth its cost when the page has to look and behave like the rest of your site while keeping the guest list with you. It also needs somebody who will still be around in a year to maintain the failed charge path, the reconcile job and the availability count. A website builder or a build puts the two routes side by side with prices, and Guesty against Hostaway is the one to read if the system underneath is still an open question.
If you want a second reading of a Hostaway quote or of a build estimate before you sign it, send it over with the number of units you run. Book a call.
