Environments

Two independent, physically separated environments. Data does not cross between them, credentials don't work across, and outbound webhook fanout is scoped to the environment that emitted the event.

Environment	Base URL	Docs	Purpose
Production	`https://api.quendoo.com/v1/qc`	`https://api.quendoo.com/v1/qc/docs`	Real hotelier data. Real bookings. Real money moving.
Staging	`https://staging-api.quendoo.com/v1/qc`	`https://staging-api.quendoo.com/v1/qc/docs`	Sandbox. Ask us for test credentials. Feature parity with prod within one release.

Which one to use when

Building or upgrading an integration — staging first, always.
Automated test suites — staging. Use the disposable-property reset described below.
Production writes from a running integration — production.
Load-testing your handlers — staging with a rate-limit bump on request. Do NOT load-test against production.

Getting staging credentials

Ask us. We mint a client_id / client_secret scoped to one or more staging properties we set aside for you. Turnaround: same business day.

What's in staging

Properties we own for sandbox use, plus any you've asked us to clone from prod. Cloning is a one-off per-property job and strips guest PII.
Every configuration surface — extras, promotions, policies, content pages, gallery, booking buttons. Preconfigured with sensible defaults so you can hit any endpoint on day one.
Bookings — you can drive real end-to-end booking creation against staging's public widget (https://staging-booking.quendoo.com/{url_key}/) and pull the revision through getBookings.

What's NOT in staging

Payment processing. Card transactions are stubbed — every card charges as approved. Do not test real cards.
Real emails to real people. Every outbound email routes to a Mailtrap-style capture — visible in your dashboard's dev tools.
Real webhook targets outside your allow-list. Staging refuses to POST outside a per-client allow-list of hosts; add yours via the dashboard.
99.9% SLA. Staging is best-effort. Overnight maintenance windows on staging are frequent — a nightly cron rebuilds it from a fresh seed.

Environment differences that will bite

Rate limits. Staging runs the default budgets (see rate limits) whatever your production budget is. Ask us for a bump if load testing.
Latency. Staging runs on smaller instances; p95 is 2–3× prod. Do not use staging latency to size prod capacity.
Data volume. A staging property has 10–50 bookings; prod has 10 000+. Reads that scale linearly with row count feel instantaneous on staging.

Resetting a staging property

For automated test suites: POST /v1/qc/staging/properties/{ext}/reset wipes every bookable calendar row, every booking, every custom policy back to the seed state. Configurations you pushed via QC (extras, promotions) are preserved unless you pass ?full=1. Not available in production.

Isolation

Auth: separate client_id / client_secret per environment. Presenting a staging client to prod → 401.
Webhooks: subscriptions are scoped per environment; a staging subscription can only fire from staging events.
Data: physically separate databases.
Rate limits: separate buckets — burning staging's budget does not affect prod.

Domains + CORS

The public booking widget's domain is per-environment too: booking.quendoo.com (prod) vs staging-booking.quendoo.com (staging). Both are served from https:// only; HTTP 80 redirects to HTTPS 443.

CORS is set to allow every origin for GET/OPTIONS under /v1/qc/*, and to reflect Authorization; per-origin allow-lists are per-client_id and configured with us. Set them tight in prod.