Quendoo Connect

Quendoo Connect (QC) is Quendoo's first-party integration API for property management systems and channel partners. Built inside the platform, versioned inside the URL, documented alongside the code that answers it — the same team that runs Quendoo's booking engine runs this API. One signed HTTPS API covers the whole loop:

• read the hotelier's property structure — room types, rate plans, calendars;
• push availability, prices and stay restrictions into Quendoo's calendar (Quendoo's own channel sync distributes them onward to the OTAs);
• receive bookings through a revision feed you acknowledge at your own pace, with webhooks as an optional low-latency trigger;
• configure the hotel — policies, promos, extras, gallery, website content, auto-emails, review replies — as first-class CRUD, so a partner can onboard a hotel end-to-end without asking anyone to open the Quendoo dashboard.

Choosing an integration path? The Why Quendoo Connect page is the 3-minute pitch — the ten differentiators, the stakeholder breakdown, the comparison against off-the-shelf channel managers and legacy vendor PMS APIs. Read it first if you have not yet decided.

Why Quendoo Connect (60 seconds)

• First-party, not middleware. Same team, same repo, same domain writes as the Quendoo dashboard — not a mirror of a legacy DB.
• Bookings as an append-only revisions feed. Miss a webhook — no problem, the ledger is the source of truth and you advance a cursor at your own pace.
• Inventory writes land in Quendoo's own calendar. One push per rate-day — Quendoo's channel sync distributes onward to the OTAs. You never double-push against a distribution layer.
• Shadow-diff harness proves partner writes match dashboard writes byte-for-byte before an endpoint promotes to live mode.
• Legacy PMS v1 has a byte-parity façade. Migrate one method at a time, rollback is one URL change.
• Three-axis authorization — scopes × properties × endpoints, each independent. Account-scoped tokens auto-follow new properties.
• 24-hour idempotency contract, 4-bucket rate limits with visible budget, one stable envelope, one machine-readable error dictionary.
• The whole hotel — policies, promotions, extras, gallery, website, auto-emails, review replies, analytics — is a QC CRUD, not just inventory.
• Docs deploy with the code. No wiki, no PDF, no drift.

Full narrative on the Why Quendoo Connect page.

What it is (in one paragraph)

QC is not a re-badge of an off-the-shelf channel manager and not a thin CRUD façade on top of a legacy DB. It is a native surface of the platform: the same use cases the Quendoo dashboard writes through, the same idempotency, the same shadow-diff harness for verifying that a PMS partner's writes reproduce what the hotelier would have written by hand, the same booking-revisions ledger the platform's own consumers subscribe to. It is versioned in-URL, tests live next to the code that answers it, and every partner sees the same OpenAPI, integration guide, error dictionary, changelog, and machine-readable index at the URLs listed below.

Where to start

0. Why Quendoo Connect — the case for choosing QC over off-the-shelf channel managers and legacy vendor PMS APIs. The ten differentiators, the stakeholder breakdown, the comparison grid. Read this if you have not yet decided.
1. Quickstart — five minutes from zero to your first successful call: token → property → inventory push. Read this if you just want to see it work.
2. Wire conventions — the shapes every response follows: envelope, ids, names + translations, money, pagination, filters, statuses, errors, PII. One page you read once and then know how to interpret every endpoint.
3. Integration guide — the end-to-end walkthrough. One fictional hotel, complete copy-pasteable requests, from your first token to your first acknowledged booking, plus every configuration surface.
4. Concepts — how the domain works. Read these before you design your sync:
   • 🏨 The domain model — properties, room types, rate plans, calendars
   • 💰 Pricing — sell types and occupancy codes
   • 📥 Inventory writes — availability, prices, restrictions
   • 📖 Bookings — the revisions feed and acks
   • ⚙️ Configuration surfaces — extras, promos, policies, age groups, gallery, reviews
   • 📊 Analytics — read-only metrics proxy: overview, traffic, funnel, campaigns, bookings, pace
   • 🔐 Authentication & limits — OAuth, scopes, endpoint-level scoping, rate limits
   • 🔔 Webhooks — subscribing, delivery shape, HMAC verification (Node.js / Python / PHP / curl), retry ladder
   • 🔁 Idempotency — the 24 h replay contract, choosing keys, concurrent retries
   • 🚦 Rate limits — the four buckets, the headers, pacing patterns
   • 🌐 Environments — production vs staging, credentials, isolation, staging property reset
   • 📓 Recipes — copy-pasteable workflows for the calls a running integration makes daily
5. API reference — every endpoint, every field, with a try-it console. The raw spec lives at /v1/qc/openapi.yaml.
6. SLA — uptime, response-time, rate limits, maintenance windows, incident and support response times.
7. Error dictionary — every error key the API can return, what causes it, and how to fix it.
8. Changelog — what's new, when, and any breaking-change migration notes. Additive-by-default under one URL major.

Already on legacy PMS v1? See the PMS v1 facade — how QC is taking over your existing apc-integrator.php calls with a byte-parity guarantee — and the migration guide that maps every PMS v1 method to its modern QC endpoint.

The shape of every response

Success responses share one envelope:

{ "status": "ok", "message": "ok", "data": { } }

Errors share another:

{ "status": "error", "message": "errors.qc.unknown_room_type" }

message is always a stable machine key, never prose — match on it, don't parse it. The error dictionary lists every key.

Environments

Integrate against staging first. The integration guide assumes staging throughout.

Machine-readable docs

Every page here has a raw-markdown twin — append .md to its URL. A compact index for LLM tooling is served at /v1/qc/llms.txt.