Developers building a direct booking page on Guesty work with two APIs, documented on two separate sites, and the owner paying for that work should know what each one covers. The Open API reads and writes everything in the account, at open-api-docs.guesty.com. The Booking Engine API covers the checkout calls for a direct booking website, at booking-api-docs.guesty.com. Your checkout requests a reservation quote, Guesty guarantees that price for 24 hours, and the quote becomes either an instant reservation or an inquiry you or your staff confirm inside Guesty later. Nothing in the documentation says the dates are held while the guest pays.
Which of the two APIs your checkout should talk to
The two APIs share a sign in, and either one lets your site pull information out of Guesty and send updates back in without anyone opening the dashboard. Inside your Guesty account you create an app. The app is an integration that logs in by itself, using a client id and a secret that work as its username and password. Both are kept on your server.
Signing in returns an access token, a temporary key, and your site sends that key with every request. Guesty's authentication page says a token lasts 24 hours and that each app may generate five per 24 hours (Guesty counts them against the app's client id). Save the token and reuse it until it expires. Request a new token on every page load and your site hits the five a day limit. After that the booking page stops taking bookings.
The second limit is on requests a minute. Guesty's guide to moving a website onto the Booking Engine API puts it at 500 a minute on the booking side and 120 on the Open API. A search page that prices several apartments across a range of dates can run through a minute's allowance quickly. The higher Booking Engine limit keeps that page from slowing down or timing out.
Your checkout requests a quote for the dates and the unit, and Guesty returns a price it guarantees for 24 hours. Each booking starts from a quote of its own. Most direct booking pages turn that quote into an instant reservation, which lands in Guesty already confirmed. An inquiry sits in Guesty until you or your reservations staff accept it.
| What you want to do | What Guesty gives you |
|---|---|
| Take a booking from your own checkout | A quote, then an instant reservation or an inquiry |
| Keep the dates off sale while the card clears | Not documented. The quote guarantees the price for 24 hours |
| Get notified when a booking changes | Webhooks, retried for about 27 hours, switched off after 5 days of failures |
| Get access | An app you create in your Guesty account: a token that lasts 24 hours, five a day |
| Read the reference | open-api-docs.guesty.com for the account, booking-api-docs.guesty.com for the checkout |
Every row above checked on September 2026 against Guesty's own documentation.
If you are comparing Guesty with Hostaway, the Hostaway API behaves differently when a card fails: what the Hostaway API lets you do covers a flow where the reservation is deleted if the charge does not go through.
What breaks after you go live
A live integration runs into documented behaviors that cost you time if you meet them after launch.
Guesty can send the same change three times, in any order. When a booking changes, Guesty tells your site without being asked, by sending an automatic message, a webhook, to an address you register with it. Guesty's reservation webhook reference says a single alteration can produce three deliveries and tells you not to rely on the order they arrive in. Your code has to process a duplicate without creating a duplicate record, and it should read the current reservation from the API before it acts on anything. Skip that and your guest gets three confirmation emails for one change.
Guesty is changing what those messages contain. The same page says the newer v2 messages no longer carry the financial details, and that the older legacy messages that still include them are retired at the end of 2026. The legacy messages have about three months left. Anything you build that takes a total from the message will stop working on that date, so read the money off the reservation.
Guesty retries a failed delivery, then stops sending to that URL. Guesty's webhook documentation publishes the retry schedule: 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours and 10 hours again, about 27 hours of trying. After 5 days of failures Guesty switches that URL off. An expired SSL certificate, the standard security certificate on your website, makes every delivery fail. Five days later the URL is off, and recovering the bookings that changed in the meantime is a manual job.
A new reservation needs a moment before you alter it. Guesty's documentation on the creation flow asks you to allow up to 60 seconds between creating a reservation and changing it. If your checkout writes the booking and then adds a cleaning fee or a note, put that delay in your code.
The two decisions we had to make on our own build
At our own place in Vienna, MINT @Naschmarkt, we run 18 serviced apartments in five apartment types, and in August we settled on Guesty as the place the calendar will live. We are not live on it yet. Most of the planning went on two things: what to do about repeated messages, and where the card gets charged.
Our invoicing code assumed each booking notice arrives once. A second copy of the same notice can arrive. A few bookings were invoiced three times each, because checking whether an invoice already existed and writing one were two separate steps, and the second notice landed in the gap between them. Your code should write a row marking that booking as invoiced first and generate the invoice second. The second and third copies of the message see the row and stop. Guesty's documentation warns about this case.
Deciding how to process cards took longer. Guesty can put the payment through its own arrangement or through your Stripe account, and we are keeping ours. Charging on our own Stripe account saves 1% per transaction. The catch is that Guesty applies its own gateway fee to every transaction that runs through your Stripe account, at a rate it does not publish. When we went looking for it, outside examples ran about 1% to 3.5%, and we still do not have a number in writing for our own account. Our guest facing site stays 100% ours, running on our own code.
Should you build on it at all, and what will it cost?
Guesty will host a booking page for you, and for plenty of small properties that page is enough. A custom build makes sense if you need a checkout of your own design and want to keep the guest list yourself, and if you have the budget to maintain the software after launch. The cheaper option is a ready made booking website, and a website builder or a build sets the two side by side.
The licence is the first cost. Guesty's pricing page puts Lite at $9 a month per listing plus 1% of each reservation, and describes that plan as suited to 1 to 3 listings. Pro is described as the plan for 4 to 199 listings and is priced by its sales team. The plan comparison does not state which tier includes access to the APIs, so ask the sales team on the first call.
Then there is the build. Our own move is scoped at 4 to 6 engineering weeks, plus 2 to 4 weeks running the old system and the new one next to each other until the new one matches. A smaller job on an account you already have costs less. Most of what is left is testing, because every one of those behaviors has to be verified on a real Guesty account before you point the site at it.
Three fees can land on a direct booking, and the third belongs to Guesty For Hosts, a separate product from the main platform.
| What you pay | Published rate | Where it shows up |
|---|---|---|
| Guesty's gateway or application fee | None published | Taken by Stripe for Guesty, so it never reaches your Guesty invoice |
| GuestyPay card processing | 2.9% plus $0.30 in the US | Guesty's help center, billed as a separate fee |
| The upgraded Vrbo connection on Guesty For Hosts | 1% per transaction | On the invoice, on its own product line |
Every row above checked on September 2026 against Guesty's own pages.
Guesty publishes the rate for only one of the two fees on a card payment. Its article on the payment gateway fee sets out when the fee applies, which includes holds, deposits and attempts the bank declines. It never says how much. The payout walkthrough works its example at "Assuming a 1% payment gateway fee", a figure chosen for the illustration. Send these three questions in an email before you sign anything:
- What percentage is the gateway fee on my own Stripe account?
- Which plan do I have to be on before either API is switched on for me?
- If I refund a guest, do you refund your fee? Stripe's documentation on direct charges says the platform's fee stays with the platform unless the platform chooses to give it back.
You need that percentage before you can compare a direct sale with a platform sale. Where the card is charged is a separate decision, and Stripe or the vendor's own payments sets out what changes when the software company holds the money.
If you want a second read on a Guesty quote before you sign it, send it over with the number of units you run. Book a call.
