Property management systems
Rooms, rates, availability and stays for lodges and hotels. Read for planning, written back when a booking is made.
Platform · Integrations
We connect to the systems you run. We don't ask you to replace them.
Your reservation system, PMS and accounting stay the systems of record. Nova reads from them, writes back to them, and agrees in writing what moves, how often, and who owns it.
How we think about integration
Every travel business we meet has a stack with history: a reservation system chosen a decade ago, a PMS per property, a channel manager, a payment provider, a CRM nobody fully trusts, and a shared inbox that is quietly the most important system of all.
We don’t start by asking you to change any of it. Nova’s modules sit alongside your systems and share one data layer, the operational truth every module reads. Integration is how that layer stays true: what comes in, how fresh it is, and where changes go back out.
The honest answer to do you integrate with X? is almost always it depends on what X exposes, and what you need from it. That’s why we describe integrations by category below, and why we’d rather give you a specific answer on a call than a logo wall.
Systems we connect, by category
We list categories rather than brands. What matters is what your particular system exposes, and what each module needs from it.
Reservation and tour systems
Departures, allotments, bookings and passenger details for operators and DMCs.
Channel managers
Availability and rate distribution, so AI agents and assistants see the same inventory as every other channel.
GDS and bedbank feeds
Wholesale accommodation and transport content, mapped and deduplicated against your own products.
Payment providers
Deposits, balances, refunds and payouts, reconciled by Booking Flow. Card data stays with your provider.
CRMs
Traveler profiles, consent records and history, so proposals and messages start from what you already know.
Messaging channels
Web chat, WhatsApp, SMS and email, for Concierge conversations, supplier requests and traveler updates.
Mapping, transit and weather data
Travel times by mode, transit schedules and hourly forecasts that feed Route Engine and live re-planning.
Data warehouses
Clean, documented exports of bookings, signals and outcomes into the warehouse your analysts already use.
Side by side
Integration patterns
Most projects use two or three of these. We choose based on what your systems expose and how fresh the data needs to be.
AspectBest forWhat we watch
REST APIsLive reads and writes (availability, bookings, routing requests) where a system offers a documented APIRate limits, versioning and authentication. Retries and back-off are built in from day one.
WebhooksPushing changes the moment they happen: a confirmation, a cancellation, a re-planned dayDelivery. We sign payloads, retry on failure and keep a replayable event log.
CSV and SFTPSystems without an API, nightly rate and content loads, suppliers who live in spreadsheetsFreshness. Every file is validated against its contract, with an alert when one is late or malformed.
Model Context Protocol (MCP)Exposing your catalog, availability and checkout to AI assistants through Agent GatewayPermissions and policy. Agents get scoped tools, never raw database access.
Email and documentsSupplier confirmations, PDFs and fax-to-email, read by Booking FlowConfidence. Low-certainty reads go to a person, not into your system.
Data contracts
Every connection starts with a contract, written down
Integrations tend to fail quietly. A supplier renames a field, a nightly export stops arriving, a rate goes in as text. So every connection we build starts with a short data contract that both sides sign off, and our monitoring checks it every time data moves.
- Fields and types. What each record contains, required versus optional, units and time zones.
- Freshness. How often data arrives, and how old it may get before modules stop trusting it.
- Ownership. Which system is the source of truth for each field, and who on your team to call about it.
- Failure behavior. What happens when data is late, malformed or contradicts itself.
- Privacy scope. Which traveler fields are needed, which are excluded, and how long they're kept.
How it works
How we scope an integration
Usually inside a Discovery Sprint or the first weeks of a pilot. Typical timings below; your stack sets the real ones.
- 01
Map the stack
Week 1We list every system, who owns it, what it exposes, and which module needs what from it. The shared inbox usually makes the list too.
- 02
Pull real samples
Weeks 1–2A week of real exports, confirmations and API responses, so we design against your data rather than against a vendor's documentation.
- 03
Write the contracts
Week 2One data contract per connection, reviewed by your team, with freshness and failure behavior agreed up front.
- 04
Build and replay
Weeks 3–6We build against sandboxes where they exist and replay recorded traffic where they don't, so the first live day isn't the first test.
- 05
Monitor in production
OngoingFreshness alerts, schema-drift detection and a regular integration health report. When an upstream system changes, we usually notice before you do.
Questions
Frequently asked questions
Do you integrate with our specific vendor?
We describe integrations by category, not by brand, because the honest answer depends on what your version exposes and what you need from it. Send us your system list and we'll tell you on a discovery call whether it's a standard API connection, a file exchange, or real engineering work.
What if our system has no API?
Then we use what it does have: scheduled exports over SFTP, CSV uploads, email, or events from a neighboring system. Some of the most reliable integrations we run are a well-validated nightly file.
Who owns the data and the integration?
Your data is yours, and so are the contracts that describe it. Custom connectors built for you under a build partnership are covered by your agreement; standard platform connectors are maintained by us. See engagement models.
What happens when a connected system changes?
Contract checks catch it, whether it's a missing field, a new format or a late file, and alert us. Modules stop trusting stale data rather than acting on it while we fix the connector. How we protect data in transit is on security & trust.
Related
Keep exploring
- ServicesTravel Data Engineering & IntegrationContent mapping, deduplication, supplier truth and data contracts that unify reservation, PMS, CRM and supplier data into one travel-shaped warehouse.
- ResourcesDevelopersREST API, webhooks and MCP access to itineraries, routes, quotes, bookings and signals. OAuth 2.0, environment-scoped keys, sandbox access by request.
- PlatformSecurity & trustHow Nova protects traveler data and keeps AI grounded: encryption, least-privilege access, prompt-injection defenses, PII minimization and incident response.
- Field Notes · Data & AnalyticsSupplier Truth: Content Mapping, Deduplication and the Data Behind PersonalizationPersonalization fails on a messy catalog. A practical guide to content mapping, match scoring, field-level authority and freshness for travel suppliers.
Send us your system list
A list of what you run, even a photo of a whiteboard, is enough to start. We'll come back with the patterns that fit, what the data contracts would cover, and where the real work is.