By the time a villa operator is running five or more specialized tools, each one is doing its job well — and none of them talk to each other in a way that gives you a single, trustworthy picture of the portfolio (the operator-platform context for this is laid out in multi-property operator platforms in 2026). The instinct to "replace it all with one platform" is almost always wrong: you'd be rebuilding a PMS, a pricing engine, a market-data product, and an operations platform that already work. The right move is to build a thin backbone that sits beside these tools, ingests their data into one canonical model, reconciles the disagreements, and serves a unified view.
This is the engineering playbook for doing exactly that. It assumes the common stack — Cloudbeds (PMS, channel manager, booking engine), PriceLabs (dynamic pricing), AirDNA (market data), Breezeway (operations) — but the pattern generalizes. Every API claim below is checked against the current developer documentation, including the parts vendors don't put in the sales deck.
Step 1 — Audit the existing tool stack and its data
Before any code, inventory what each tool actually holds and, critically, what plan you're on — because API access is frequently gated by tier.
Walk the stack and write down, per tool: which business entities live there, who owns the account, the subscription tier, and whether your tier includes API access. For the canonical stack that means: Cloudbeds holds reservations, guests, rooms/room-types, rate plans, and transactions. PriceLabs holds pricing decisions (computed nightly rates, minimum-stay rules) and, through its market products, neighborhood comparables. AirDNA holds market-level analytics — occupancy, ADR, RevPAR, comparable sets. Breezeway holds operational tasks, inspections, maintenance, supplies, and the costs attached to them.
The audit's real output is a list of overlaps, because overlaps are where conflicts will later come from. Two tools hold reservation data (Cloudbeds as the source; Breezeway as a synced copy it uses to schedule cleans). Two tools hold market data (AirDNA and PriceLabs' Market Dashboard). Two tools have an opinion about price (PriceLabs computes it; Cloudbeds stores what was actually charged). Note every overlap now.
Step 2 — Map data flows and declare a source of truth per entity
This is the most important step, and it's a design decision, not a technical one. For every entity and ideally every field, exactly one system is the source of truth, and everything else is a copy.
A clean assignment for this stack:
- Bookings, availability, rates charged, transactions → Cloudbeds. It's the system of record for what was sold, and the substrate for any direct-booking engine you layer on top.
- Pricing decisions (nightly rate, min-stay restrictions) → PriceLabs. It computes them and writes them back into the PMS; your backbone reads them, it doesn't recompute them.
- Operational tasks, maintenance, operating costs → Breezeway.
- Market benchmarks (occupancy/ADR/RevPAR of comparables) → AirDNA, or PriceLabs' Market Dashboard if AirDNA's API isn't accessible (more on that in Step 3).
Two entities belong to none of the tools and must be owned by your backbone: the canonical Property (each tool has its own property record and its own ID for it) and the Owner with their contract terms (no operational tool models per-owner revenue share). Draw the flow as a directed graph. If two arrows point write-authority at the same field, you have a bug waiting to happen — resolve it on paper first.
Step 3 — Verify API access per tool (this is where projects get surprised)
Do not design against what the marketing page implies. Pull each developer doc and confirm auth, available entities, event support, and rate limits. Here is what's actually true today.
Cloudbeds exposes a REST API (with a GraphQL option) authenticated via OAuth 2.0 with scoped permissions. It covers reservations, guests, rooms, rate plans, and house accounts, plus specialized sub-APIs: a Data Insights API for reporting and an Accounting API for transactions. Crucially, it supports webhooks — you register an endpoint and receive events for reservation/created, status changes, date changes, room-assignment changes, and deletions. This makes Cloudbeds the one tool you can sync in near-real-time.
PriceLabs offers a REST API keyed by an X-API-Key from the dashboard. Its Customer API lets you read computed rates and push date-level overrides and base-price rules; a separate integration API exists for PMS-style connections; and the Revenue Estimator API plus Market Dashboard expose market data. Note the commercial detail: PriceLabs charges roughly $1 per listing per month for listings syncing via the API. PriceLabs is pull-oriented and scheduled — there are no booking-style event webhooks to subscribe to.
AirDNA is the gotcha. Its API is enterprise-only: you authenticate with a Bearer token issued by an account manager after a sales conversation, typically on an annual contract priced accordingly. There is no self-serve key. For a 20-to-80-villa operator this often means AirDNA's API is out of budget or out of timeline, even though the AirDNA dashboard subscription is affordable. Plan for one of three paths: buy the enterprise tier, get market data from PriceLabs' Market Dashboard (which you may already pay for), or use a pay-as-you-go market-data API as the comparables source. Decide this before you design the schema, not after.
Breezeway provides a REST API authenticated with a JWT, covering properties, reservations, and task & cost data, plus webhooks you subscribe to via /public/webhook/v1/subscribe with a task or property-status type. Read the fine print: Breezeway's webhook docs say notifications arrive "within an hour" — so this is near-real-time, not instant. That single fact changes how you design Step 5.
The takeaway: you have two webhook-capable tools with different latencies (Cloudbeds near-instant, Breezeway near-hourly) and two pull-only tools (PriceLabs scheduled, AirDNA batch/enterprise). The architecture has to be a hybrid.
Step 4 — Design the unification data model
Use a relational database — PostgreSQL is the obvious default for its JSONB support and transactional integrity. The model has three layers.
Canonical entities you own: properties, owners, and owner_property_contracts (encoding revenue-share, flat-fee, or hybrid terms, plus who bears OTA commission and card fees).
Synced entities mirrored from the tools: bookings, expenses, tasks, market_snapshots. Every one of these carries two columns that are non-negotiable: source_system and external_id. You never store a foreign tool's row without recording where it came from and its native identifier.
Plumbing that makes the whole thing debuggable: an id_map table (source_system, external_id, internal_id) that translates each tool's identifiers into yours; a raw_events table that stores the untouched payload of every webhook and poll, in JSONB, before any normalization; and a sync_log recording every ingestion, success or failure.
The discipline here is simple and saves you for years: store the raw payload first, normalize second. When a vendor changes a field or a sync goes wrong, the raw event is your ground truth and your replay source.
Step 5 — Build the hybrid sync architecture
Because the tools have different capabilities, the sync layer is a hybrid of webhook ingestion and scheduled polling.
For Cloudbeds and Breezeway, stand up a webhook receiver endpoint per provider. Each receiver does the minimum synchronously: verify the request is authentic, write the raw payload to raw_events, enqueue a job, and return 200 fast. Verification and an idempotency key matter because webhooks get redelivered — a reservation-created event arriving twice must not create two bookings. Deduplicate on the provider's event ID. A queue (even a simple one) decouples receipt from processing so a slow normalization step never causes the provider to think your endpoint is down.
For PriceLabs and AirDNA, run scheduled pollers — PriceLabs hourly or a few times a day for rate changes, AirDNA daily or weekly for market snapshots, since market data moves slowly and enterprise calls are metered. The poller writes to the same raw_events table, so downstream normalization doesn't care whether data arrived by push or pull.
Normalization is a separate worker that reads raw_events, maps external IDs via id_map, upserts into the canonical tables, and marks the event processed. Build in retries with backoff and a dead-letter path for events that repeatedly fail, so one malformed payload never silently stalls the pipeline.
Step 6 — Establish a single owner view across tools
The owner-facing view is assembled from your unified database, not from live calls to four APIs at page load — that would be slow, rate-limited, and fragile. Your sync layer already keeps the canonical tables current; the owner view is just a read model on top.
For a given owner, join their properties to bookings (from Cloudbeds), tasks and costs (from Breezeway), current pricing (from PriceLabs), and market position (from AirDNA or the Market Dashboard). Apply row-level security so every query is scoped to that owner's properties and an owner can never see another's data. The result is the thing none of the four tools can produce alone: one screen where an owner sees their bookings, their net position, their maintenance, and how their property is performing against the market.
Step 7 — Cross-tool reporting: RevPAR, maintenance, and market in one place
This is the payoff. With the canonical model in place, you can compute reports that span tool boundaries.
Compute RevPAR from Cloudbeds bookings, defining available nights honestly — net of owner-blocked nights and Breezeway maintenance closures, which is itself a cross-tool calculation (revenue from one system, unavailability from two). Overlay maintenance and operating cost from Breezeway against that revenue. Then place both next to market RevPAR for the comparable set from AirDNA or the Market Dashboard.
A single line now reads: "This villa did a RevPAR of X, the market did Y, and it cost Z in maintenance to get there." No individual tool can say that sentence. Implement these as materialized views or a scheduled aggregation job rather than computing them on every request — portfolio-wide RevPAR across dozens of villas is too heavy to recompute live.
Step 8 — Resolve conflicts when the tools disagree
They will disagree, and a serious backbone has explicit rules for it rather than hoping it won't happen. Common collisions: Cloudbeds shows a property booked while Breezeway has it flagged vacant; PriceLabs pushed a rate that the PMS, for some reason, didn't apply; a property's bedroom count differs between Cloudbeds and Breezeway.
The resolution rules follow directly from Step 2. Per field, the declared source of truth wins — a non-authoritative system never overwrites an authoritative field, full stop. "Last-write-wins" applies only within the same authority. Every record keeps a timestamp and provenance so you can reason about ordering. And anything the rules can't resolve automatically goes to a review queue surfaced to a human, not silently coerced into one value. Silent coercion is how operators end up sending an owner a statement built on a number nobody can explain.
Step 9 — Maintain an audit trail across tool boundaries
Because every synced row carries source_system, external_id, and a received-at timestamp, and because every change is appended to an immutable log, you can trace any figure back to its origin across tools. When an owner questions a payout six months later, you can walk it from the statement line, to the canonical booking, to the exact Cloudbeds transaction and the Breezeway task whose cost was deducted.
This is event-sourcing-lite: you don't need a full event-sourced system, but you do need an append-only history of what changed, when, and from which source. It pays off twice — once in owner trust, and once in compliance, since an auditable chain of provenance is exactly what regulators and serious buyers want to see.
Step 10 — Build the operator dashboard on the unified data
The last piece is the internal cockpit your own team runs the business from, built on the same read model as the owner view. It shows portfolio RevPAR and occupancy, the maintenance backlog from Breezeway, market position, and per-owner net positions.
The feature most teams forget is the most important one: sync health. The dashboard must show, prominently, when an integration is stale or failing — when the AirDNA poll last succeeded, whether Cloudbeds webhooks are flowing, whether any events are stuck in the dead-letter queue. A dashboard that quietly displays last week's market data as if it were live is more dangerous than no dashboard, because people will make decisions on it. Make staleness visible.
What you end up with
The backbone is deliberately thin. It does not replace Cloudbeds, PriceLabs, AirDNA, or Breezeway — each keeps doing the job it's good at. It adds exactly four things on top: a canonical model the tools don't share, a sync layer that respects each API's real capabilities, a reconciliation policy for when they disagree, and a unified read model that powers both the owner view and your operator dashboard.
Done this way, unification is an integration project measured in weeks, not a platform rebuild measured in quarters. And the moment it's live, you can answer the question every multi-property operator struggles with and no single tool can: across the entire portfolio, how are we actually doing — against ourselves, against our costs, and against the market?
If you're staring at a five-tool stack and a spreadsheet trying to hold it together, this is the kind of backbone we build for hospitality and villa operators — designed around each tool's real API, not a sales-page promise, and shipped through our direct booking and guest platforms service. The first step is always the data-flow map from Step 2; get that right and the rest is implementation.
Reviewed by the H-Studio Indonesia editorial team.
Important disclaimer. This article is general engineering guidance for multi-property operators, not vendor-specific advice. API capabilities, authentication, pricing, webhook behavior and rate limits at Cloudbeds, PriceLabs, AirDNA and Breezeway change without notice and may vary by region, contract and subscription tier. Verify each integration scope against the current developer documentation and your own account access before committing engineering work. Indonesian-specific rules around data handling (UU 27/2022), KBLI 2025 classification, and operator licensing apply independently and should be confirmed with qualified Indonesian advisers.
