Why Quendoo Connect

Quendoo Connect is the only PMS/channel API that is Quendoo itself. Not a middleware translation layer. Not an OTA-only channel manager. Not a legacy stored-procedure endpoint wearing an HTTP hat. The team that runs Quendoo's booking engine writes and operates this API, and it reads and writes the same domain the hotelier's own dashboard reads and writes.

That single fact is the reason for everything else on this page.

The one-slide pitch

Read this if you are choosing a PMS integration path for a hotelier's Quendoo account, choosing a channel/inventory partner for your own hotel, or picking which vendor API to integrate first — this page is the pitch. Everything below is what the technical pages already prove, framed for a decision.

Ten things we thought through so you don't have to

1. Bookings are a revision feed, not a webhook you have to trust

Every meaningful change to a booking becomes a revision appended to a ledger and served through GET /bookings/revisions. You acknowledge each revision when you have durably persisted it — no ack, no advance. Webhooks exist as an optional low-latency trigger, but the feed is the source of truth, so a missed HTTP call cannot cost you a booking. Multiple consumers can subscribe with independent cursors — PMS in one process, reporting in another, none of them coupled.

See Bookings & the feed.

2. Inventory writes land in the same calendar the hotelier writes

Availability, prices and stay restrictions push into Quendoo's own calendar. Not a mirror, not a shadow — the same rows the dashboard edits and the booking engine sells from. Quendoo's channel sync distributes them onward to the OTAs; you push once, to one place, and never double-push against a distribution layer you did not build.

See Inventory writes.

3. A shadow-diff harness proves your writes match what the hotelier would type

We run every partner write through a shadow diff: the payload is applied in a scratch context and compared byte-for-byte against what the same write would have produced through the hotelier's dashboard. A mismatch is not "good enough" — it is a bug, and it blocks promotion of that endpoint to live mode until it disappears. That is why the first go-live of a partner integration is measured in days, not quarters.

4. Migrations from the legacy PMS v1 API carry a byte-parity guarantee

Every route the legacy apc-integrator.php served has a QC façade at /v1/qc/pms-v1/*. Responses are byte-parity with the old endpoint under a locked test corpus. You upgrade one method at a time, from your existing credentials, with a rollback that is literally "change one URL back". This is the anti-thesis of the "we're deprecating v1, migrate by Q4" experience every other vendor forces.

See PMS v1 facade and the migration guide.

5. Auth is three independent axes, not a checkbox

A token carries scopes (categories of action — inventory.write, bookings.read, …), properties (which properties it may act on) and endpoint scopes (which specific routes it may hit, with per-resource wildcards). Every request must clear all three. That means one integrator role can hold inventory.write on 40 properties but only for the availability endpoint, while another holds bookings.read on the same 40 properties. This is what real least-privilege looks like — most vendors give you "read all or write all" and call it security.

See Auth, scopes & limits.

6. Account-scoped tokens auto-follow new properties

Ticked the "account-scoped" flag on a token? It has no fixed property list. Every request re-resolves your account's currently enrolled, active properties in real time. A property enrolled tomorrow becomes reachable without rotating credentials. The one call your CI pipeline dreaded — "we onboarded ten hotels, please issue ten new tokens" — is gone.

7. Idempotency is a first-class 24-hour contract

Every write route accepts Idempotency-Key: <uuid> and replays the exact same response for 24 hours. Retry a POST after a timeout without double-writing. Repost the same booking-ack a week later — QC will tell you it is a duplicate, cleanly. Concurrent retries lock and serialise. The contract is written down with the tests to prove it.

See Idempotency.

8. Rate limits are budget you can see, not a wall you hit

Four buckets — reads, writes, bookings-feed, analytics — each surfaces its budget on every response via X-RateLimit-Remaining and X-RateLimit-Reset. Pace against the numbers, not guesswork. Tier upgrades are a config change, not a re-integration.

See Rate limits.

9. The whole hotel, not just inventory

Every configuration surface a hotelier touches in the dashboard is a QC CRUD: policies (payment, cancellation, guest data), promotions, extras, gallery, website content, auto-emails, review replies, age groups, taxes, room-type structure, rate-plan derivation, subscriptions. A partner can onboard a hotel end-to-end without asking anyone to open Quendoo. That is what "PMS-native" actually means.

See Configuration surfaces.

10. Docs deploy with the code

You are reading this file directly from the repository that answers the API calls it describes. Every merge on the API refreshes this documentation. The changelog is written by the people shipping the change. The error dictionary lists every key the API can return with a fix note. There is no wiki, no PDF, no drift.

What each stakeholder gets

For integrator engineering teams

• One API, one auth scheme, one envelope — no per-tenant surprises
• Try-it console at /v1/qc/docs/reference with your own token
• Stable machine-readable error keys — no prose parsing
• Test credentials on staging in a call; a staging property you can freely reset without touching production
• Direct line to the team that runs the platform — no vendor tier gating

For the hotelier

• Their PMS and Quendoo see the same calendar — no reconciliation spreadsheets, no "the two systems disagree about this room-night"
• Configuration lives in one place — extras, promos, policies edited in the PMS surface through immediately without a nightly re-sync
• Analytics through QC reads the same numbers the dashboard shows — overview, funnel, pace, bookings, campaigns
• Access is per-scope, per-property, per-endpoint — the PMS holds only what it needs

For agencies and multi-property operators

• Account-scoped tokens cover every current and future property under an account with no rotation
• Shared-access delegation is honoured through the acting-as context — agency staff acting under a client's account keep their permissions narrowed as configured
• The same feed powers reporting for a portfolio without polling per property
• Webhook subscriptions can be filtered per property or per account

What it is not

• Not a channel manager wrapper. Quendoo runs its own channel sync; QC is the platform, not a shim on top of one.
• Not a legacy CRUD wrapper. QC's routes are use cases the platform itself writes through — not thin SELECT * FROM façades.
• Not versioned by month. The URL major is stable; additions are additive; the changelog marks every change with its release.
• Not gated behind sales calls. You are reading it. The quickstart is five minutes and needs only a staging credential.

Where to go next

• Five minutes: Quickstart — first token, first property, first inventory push.
• End-to-end: Integration guide — one fictional hotel, copy-pasteable requests, from zero to first acknowledged booking.
• Depth: the Concepts section covers every mechanism this page names.
• Migration from legacy PMS v1: migration guide.

Ready to talk pricing, portfolio size, or a bespoke bucket tier? Contact us at [email protected] — the person on the other end runs this API, not a support tier.