A direct booking site on Cloudbeds gets its bookings from Cloudbeds and its payments from somewhere else. The API is the connection your own site uses to read and change what sits inside the property system: rooms, rates, availability, guests and reservations. Most of a checkout build comes down to a single call named postReservation, which writes a real booking into that system straight from your own page, and the reference for it is at developers.cloudbeds.com. Cloudbeds does not take the money. Its booking engine guide states that transferring credit cards or processing payments is not supported. Stripe gives your site a token in place of the guest's card number, and sending that token to Cloudbeds with the booking does not charge the deposit either, because Cloudbeds says its processing rules do not apply to reservations created through the API. So your checkout collects the money in a step of its own. Nothing in Cloudbeds holds the dates while that happens, and a card that fails leaves a live booking on the calendar for your code to clean up.
Getting a key, and the ceiling you work under
You issue the key yourself. Cloudbeds calls it a property level key, and you make it from Account and then Apps and Marketplace inside your own account. Cloudbeds expires that key only after 30 days of disuse, and nobody at Cloudbeds has to approve you before you create it.
Developers often read the Limited Release stage and its minimum of five live properties as a barrier here. Cloudbeds applies that stage to the Marketplace partner track, the process a software company goes through before it can list an integration other hotels are able to buy. Your own property reading its own data never enters that process.
Cloudbeds allows 5 requests a second for a property, which is the limit that shapes the build. It is too few for a search page that asks a fresh question about every room on every date on the screen. Pull a range of dates and rates once, keep the answer, and price from what you hold.
| What you want to do | What Cloudbeds gives you |
|---|---|
| Take a booking from your own checkout | postReservation, which writes a real booking, marked as coming from a website or booking engine |
| Charge the card | Nothing. Payments happen in your own step, outside the API |
| Keep the room off sale while the card clears | No hold is documented for a guest checkout |
| Hear about a change without asking | A message Cloudbeds sends your site, retried a minute apart, five attempts, then never again |
| Get access | A property level key you create in your own account |
| Read the reference | developers.cloudbeds.com |
Every row above checked on September 2026 against Cloudbeds' own documentation.
Deciding what happens first, the booking or the money
There are two orders available: create the booking and then charge the card, or charge the card and then create the booking. Your developer has to handle what happens when one of the two systems accepts and the other does not.
If your code creates the reservation first, it sits on the calendar from that moment. Cloudbeds marks it as having come from a website or booking engine, and reading it back returns the balance and the amount paid, so your code has somewhere to record what it later collected. If the card is then refused, nothing expires on its own: your code cancels the booking, or that room stays blocked.
The other order protects you from the refused card, since nothing has reached Cloudbeds yet and there is no booking to undo. The risk moves to the gap between the two systems: a guest who has paid while your call into Cloudbeds fails, leaving you holding money against a booking the property system has never heard of. Cloudbeds' payment documentation sets out five routes the money can take, and which route you pick decides how the rest of the integration gets built. Stripe against Cloudbeds Payments puts the two most common routes side by side, with what each one costs.
Cloudbeds does have a tool that takes rooms off the calendar, the allotment block, and operators often read it as a checkout hold. Cloudbeds built it for group business, where you set rooms aside for a party and release whatever they do not take. A block marked Definite reduces the rooms available in that room type, while a block still marked Lead or Tentative, meaning the group has not committed yet, sets nothing aside. None of that helps during a checkout, where the guest is two minutes from finishing and the room has to be theirs for those two minutes. Other systems answer this question differently: Hostaway can charge the card inside the same request that creates the booking, and deletes the booking if the charge fails, and Guesty starts from a price quote it guarantees for 24 hours.
The message that only comes five times
Cloudbeds sends your site a short message, called a webhook, to a web address you register with it, whenever a booking changes. A cancellation then reaches you within seconds, and your site never has to keep asking whether one happened. A failed delivery is retried a minute later, up to five attempts, and when all five have failed Cloudbeds makes no further calls for that event.
Five attempts a minute apart gives you roughly five minutes of tolerance. A software update that keeps the site down for six loses those notifications permanently, and nothing afterward tells you which ones went missing. Build the background check into the first version of the site: read your reservations back from Cloudbeds on a schedule, compare them with what your own records say, and correct whatever disagrees.
Cloudbeds documents no hold for a guest checkout, and it says nothing anywhere about an unpaid reservation expiring by itself, which is why canceling one has to be your code's job.
The payment that never made it back
Our own property is built on this same split, on a different system, which is how we found the failure it hides. MINT @Naschmarkt in Vienna is ours, 18 serviced apartments in five apartment types. It runs on Hostfully, and in August 2026 we decided to move it to Guesty. The money moves on our own Stripe account, and the property system only hears about it afterward. On our refundable rate a guest pays half at booking and the rest comes off the stored card five days before arrival, taken automatically.
The first time that job ran for real, it charged the card and issued the invoice correctly, and the payment was never written back into the property system. The guest had paid and our books said so, while the property system went on showing a balance owing, and the front desk would have read that balance at check in. We added the step that records a payment against the booking inside the property system, plus an alarm for the next time it fails, so a failure now surfaces on the day it happens.
If your Cloudbeds checkout charges the card outside Cloudbeds, recording that payment on the booking is your code's responsibility every single time, including the ones collected automatically weeks after the guest booked.
What does Cloudbeds cost, and should you build on it?
Cloudbeds publishes no price. Flex, One, Experience and Enterprise each end in a request a quote button. Budgeting the software means a conversation with their sales team, and a number in writing at the end of it.
What it does sell openly is the alternative to a build. Cloudbeds' own hosted website comes with the booking engine already in it, and that page claims up to 25% more direct bookings, a claim from its own marketing with no method attached. Its Marketplace adds Zapier, a connector that reaches more than 1,000 other apps without a developer.
For a property of 8 to 15 units selling mostly through Booking.com and Airbnb, with nobody on call to fix a checkout, the hosted engine is the right answer, and a custom build will cost more than it returns. You give up control of the page and you get a checkout somebody else maintains.
The case for building starts when the booking page has to look and behave like the rest of your site, or when the guest list has to stay with you. Price the build with its upkeep included. Beyond the page itself, the work does not stop. Bookings whose cards failed have to be canceled. The scheduled comparison against Cloudbeds has to run, with somebody acting on what it turns up. Every payment has to be recorded against the booking it belongs to. And the rooms your site shows as free have to be the rooms that really are free. Every one of those jobs continues for as long as the site is live. If you are already on Cloudbeds and content with it, what usually holds the direct bookings back is the booking page itself: how it looks, and how many steps a guest has to get through.
Bring us a Cloudbeds quote or a build estimate with the number of units you run, and we will tell you what it leaves out. Book a call.
