Guesty integration
We read Guesty into a warehouse that belongs to you, next to your pricing tool and your CRM. Read only, every day, with the definitions agreed up front. Then the detectors run on top and find the revenue your stack has already earned.
What we read
The connector is read only by construction. Most vendor keys can write. Ours cannot, and it checks that it is looking at your account before it loads a single row.
Five stages, and none of them can write to your systems.
Pricing context comes from your revenue tool, Wheelhouse today. Lead and owner data comes from your CRM, HubSpot today. Each source is configured by role, so swapping a tool later is one connector, not a rebuild.
Before the first number
Not because the data is bad. Because the same data supports several correct answers and nobody wrote down which one you mean.
They sit in the same collection as bookings. Sum naively and the phantom revenue can be larger than the real number. We apply a governed booked-status set in one place, visible in the interface.
Completed stays and owner blocks share it. Zero-revenue rows contribute nights but no money, so they dilute ADR and inflate booking counts. Status is a dimension, not a yes or no.
Accommodation fare, subtotal before tax, gross payout. Operators set targets on fare. Published growth tends to be gross. Both are right and they differ by a lot.
We reconcile to your own monthly report in week one and write the answers down before anything is built. The full list is in five definitions that change every number in your revenue report.
What we learned
Anyone who has built against it will recognise every one of these. We write them down because they are the difference between a number you can trust and one that is quietly wrong.
A field can exist, be populated, and be invisible. Enumerate before concluding something is not there.
Skip-offset paging without an explicit sort key returns some rows twice and drops others, while the total count still looks correct. We pass a stable sort, then fail the load if collected rows are fewer than the API reported. A partial revenue load silently understates every metric downstream, which is far worse than a visible failure.
A flat pass over tens of thousands of reservations fails partway with a server error. We slice by date window so the offset stays small. It also makes every load restartable.
Dot-path projections such as money.hostPayout return null on most rows; request the parent object instead. And some fields, custom fields among them, are absent from the default projection entirely. A field can exist, be populated, and be invisible. Enumerate before concluding something is not there.
You get user ids, not names, and the id-to-name mapping is not retrievable through the API version most accounts are on. We capture it at onboarding and budget for it.
Documented as one request a minute. Observed: after four or five requests it returns rate-limit errors continuously for over forty minutes, through every backoff ladder. We cache the access token and reuse it for its full life. One token request a day, not one per run.
An inclusive upper bound on the last day of the month drops post-midnight check-ins. Always >= start and < next start. Small, and it changes the month's revenue.
A loader that types a price column from integer-valued first rows will shunt the decimal prices that arrive later into a variant column and null the typed one. It raises no error and it changes revenue. We declare every money column and cast at the point of yield, then reconcile totals against the source.
A valid key on the wrong account returns a perfectly normal 200. We fetch the account identity and assert a known structural marker is present before a single row moves. For you it is a pre-flight you see and confirm.
Then
With two years of reservations, the roster and the money model in one place, four questions become answerable that no single tool can answer on its own.
Needs history and a place to compare it. Nothing in a standard stack computes it.
Only the ones worth a call, most valuable first.
Ranked by average stay value so today's best opportunity rises.
The quoted price is already in Guesty. The follow up can be specific.
Each one arrives as a work item with a value, a named owner and a deadline. How that works.
Guest data
The AI can read two schemas. Both were audited and contain no email address, phone number or postal address. The raw and staging layers, where Guesty's guest records land, are denied outright and verified by probe. A test fails the build if that ever stops being true.
Tell us which tools you run alongside it and what they already do for you. We will show you what is sitting in your own reservation history.