Systems we connect with

Every PMS Rezlynx module talks to your hotel platform through its documented, official API — nothing screens-scrapes, nothing borrows a login. This page explains how connections are built, what we read and write, and how credentials are handled from first contact until the day you cancel.

The connection philosophy

Two rules govern every integration we ship. First, official interfaces only: if a platform publishes an API or certified webhook surface, that is where our modules operate; if it does not, we build the connector against its supported export formats rather than fragile browser automation. Second, scoped credentials: you generate one key per property inside your own admin settings, grant it exactly the scopes a module needs, and can revoke it at any moment without touching us first.

Before any module goes live we agree an explicit read/write matrix with you in writing. A rate-parity watchdog holds read-only scopes on rates and availability plus no guest data whatsoever. The yield advisor adds write access confined to seasonal rate tables. The eSign pack touches guest profiles for arriving bookings only, and every scope is listed on the activation screen before you confirm. Nothing requests blanket administrator rights, because those would be both unnecessary and poor practice under the UK GDPR data-minimisation principle.

Host platforms in production today

PMS Rezlynx modules currently run against four broad categories of host system:

Mainstream UK cloud PMS. Guestline Rezlynx, Mews, Cloudbeds, Protel and comparable cloud platforms make up the bulk of live deployments. Certification is per-version: when a provider ships a breaking API change we re-run the full test cycle before your nightly jobs notice anything.

Enterprise suites. Opera Cloud and similar enterprise estates in larger UK groups, usually with multi-property tokens and stricter change windows negotiated case by case.

Booking-engine-first stacks. Properties whose direct channel runs on a specialist engine rather than their PMS's own booking module; the direct-booking widget integrates with either side through whichever interface exposes availability.

Legacy and file-based environments. Where an older on-premise system offers only scheduled exports, several modules degrade gracefully to batch mode overnight, reading CSV drops instead of live calls — slower but dependable, and honest about it during scoping.

Credentials procedure

You never send secrets by chat. After checkout, activation emails you a single-use upload link where the generated key is stored encrypted at rest. Keys are held by the specific module that needs them, logged in an internal register, and rotated on request or automatically every twelve months. If a scope changes, you re-issue rather than widen — widening silently is the habit that turns small leaks into audits.

Sandboxing comes first wherever a provider environment exists: we run a synthetic reservation cycle end-to-end before touching production data, then mirror go-live sign-off in writing. On cancellation the credential dies in your settings and our copies are purged within thirty days per the retention schedule in the privacy policy.

Webhook behaviour

Where your platform supports webhooks, modules subscribe narrowly: reservation created, reservation amended, rate updated, folio closed — each mapped to exactly one handler. Payloads are verified by signature, retries back off exponentially for up to twenty-four hours, and failed events park in a dead-letter queue visible on your status page rather than vanishing. If webhooks fail wholesale, affected modules fall back to interval polling so continuity is preserved; night-audit windows are avoided for all writes as standard.

Multi-property tokens

Groups manage connections from one account view. A group token lists every property with its own scoped key beneath it; dashboards aggregate across sites while permissions stay per-property. Consolidated monthly invoicing follows the same structure, and moving a property between brands takes one afternoon including key re-issue and data re-pointing.

Deprecation policy

Provider API versions have lifecycles beyond our control, so ours is simple and public: minor version drift is absorbed continuously; breaking changes trigger a compatibility release within thirty days of the provider's general availability date; anything we retire ourselves gets twelve months' notice minimum, with automated adapters bridging old payloads meanwhile. Status of each connector — certified, bridge, scheduled — appears on this page's changelog section during subscription reviews.