Systems we bolt onto
PMS Solution modules are guests in your stack, not new landlords of it. This page explains exactly how those connections are made, what permissions they carry, and how we behave when platforms change under our feet.
Official interfaces only
Every module exchanges data through the documented, versioned API of the platform it extends — cloud property management systems commonly deployed by UK independents, booking platforms exposing partner endpoints, messaging carriers with approved transactional routes, and payment surfaces reachable through your PMS's own fiscal layer.
We do not scrape screens, we never ask for a shared administrator account, and we do not touch databases directly. If a capability cannot be reached through official means, we say so plainly rather than improvising a fragile bridge that breaks during platform maintenance windows. That restraint is deliberate: it keeps your system of record authoritative, keeps upgrades reversible, and means switching a module off leaves no residue behind in your PMS.
The same discipline applies backwards. Data our modules produce — confirmed bookings, cleaned room statuses, validated invoices — is written back through the same official channels, so your night audit, reporting and accounting continue to see one coherent source of truth rather than a second shadow database that drifts out of date.
What we support in production
Categories maintained against live API versions today:
| Connection | Reaches | Typical pairing |
|---|---|---|
| Cloud PMS platforms | Availability, reservations, rate tables, guest profiles | Booking widget, dynamic pricing, housekeeping board |
| Airbnb partner connection | Listings, calendar, restrictions, reservation lifecycle | Two-way sync as a standalone channel |
| Metasearch partners | Rate-and-availability feeds, landing routing | Feed manager for Trivago, Kayak, Skyscanner |
| Messaging carriers | Transactional SMS with registered sender identity | Guest journey confirmations and reminders |
| Fiscal layer of your PMS | Charge posting, VAT breakdowns, credit notes | Folio & invoice automation |
| Edge cases | Scheduled CSV flows over secure transfer | Legacy or niche systems without modern APIs |
Naming your exact platform in a message gets a compatibility answer the same working day, including which permissions each module requests and anything your plan tier cannot expose.
Credential workflow
You generate an API key inside your existing platform's own settings area — we send step-by-step screenshots for your specific system so nobody guesses. Keys are pasted once into our activation form, transported over TLS, encrypted at rest, and never displayed again in full. Our staff can see only the trailing four characters needed for support conversations.
Each key carries the narrowest scope its module needs: a pricing engine requests read-write on rate tables but nothing else; the housekeeping board reads occupancy and writes room status; the SMS journey needs reservation dates and guest contact fields. Nothing we request touches payment card data, which stays inside your PSP and PMS fiscal layer throughout.
Rotation is self-service: replace the key from your platform, update it in our dashboard, and the old token dies at once. Revoke entirely and all modules holding that scope stop politely — no orphaned jobs, no silent retries hammering a dead endpoint.
Checklist before go-live
Scope review together
We walk the requested permission list line by line before activation, and remove anything the module can live without.
One test cycle
A booking, a status change and an invoice are pushed into a test space first, then verified against live data structures.
Named contact
Your activation record lists the engineer who configured the connection, so day-two questions reach a person who knows it.
Webhook behaviour
Inbound events arrive as signed payloads, verified per delivery against a rotating secret, with a five-minute replay window to defeat duplicates. Failed deliveries retry on an exponential schedule for twenty-four hours, then park in a queue you can inspect from the dashboard alongside the raw payload and response codes. Every consumer route is idempotent, so replays reconcile cleanly instead of double-posting charges or shifting the same room twice.
Tokens across a portfolio
Multi-property operators receive one scoped key per property rather than a master credential. A group dashboard aggregates the views, yet any single key can be rotated or revoked without disturbing siblings. Staff access follows role templates — housekeepers see boards, revenue leads see pricing, owners see everything — and every administrative action lands in an immutable log retained twelve months.
Deprecation policy
Platform APIs evolve, and pretending otherwise would be dishonest. Our published commitment: when a connection method must change, affected customers receive written notice at least ninety days ahead, describing what changes, why, and the precise action required on their side — usually none, because we migrate server-side wherever the platform allows.
During transitions we run old and new methods in parallel, reconcile outputs, and only cut over after a clean comparison window. Modules affected by platform-side price or packaging alterations are flagged before renewal, never discovered at invoice time. Where a third party withdraws an interface outright — it has happened twice in our history — we honour remaining paid months pro rata and help you land the replacement workflow.
The same courtesy runs inward: if we retire a module feature, existing configurations keep working until the next natural renewal, with a written alternative in hand.
Name your stack, get a straight answer
Tell us the PMS, channel manager and site platform you run — compatibility comes back the same working day.