PMS Certification Readiness
How this integration meets the Channex PMS certification tests.
Pre-flight requirements
| Requirement | How it's met |
|---|---|
| Event detection (not polling) | inventory.changed / rate.changed SNS events drive ChannexAriEventConsumer; no timer-based diffing |
| Queue / outbox respecting the ~20 ARI/min limit | SQS queue feeds the consumer; ChannexRateLimiter paces ARI calls to 20/min |
| Retry / backoff on 429 & 5xx | ChannexApiClient.retry — exponential backoff, honours Retry-After on 429 |
| Webhook endpoint with ack | POST /api/channex/webhook → store → ack the revision |
| UUID mapping layer | channex_property / channex_room_type map our ids → Channex UUIDs |
Test scenarios
| Test | Behaviour |
|---|---|
| 1 — Full sync (500 days) | Range-compressed; one /availability + one /restrictions call (batch up to channex.ari.max-batch) |
| 2 — Single date/rate | One real edit → one event → one push (no scripts) |
| 3–4 — Multiple rates / dates | Coalesced per batch into one call — no per-date looping |
| 5 — Min stay | min_stay_arrival pushed from inventory.minimumStay |
| 6 — Stop sell | stop_sell pushed (and availability zeroed) |
| 7 — Multiple restrictions | min_stay_arrival, max_stay, stop_sell in one call (see capabilities below) |
| 8 — Half-year | Range compression keeps it to one call |
| 9–10 — Availability | Booking/inventory change → availability push (holds netted out) |
| 11 — Booking lifecycle | GET /booking_revisions + ack per revision; webhook + feed; create/cancel applied, modify flagged |
| 12 — Rate-limit compliance | ChannexRateLimiter (20/min) on the production path |
| 13 — Delta-only | Delta pushes on events; full sync only via the nightly drift job (≤ once/24h, off-peak) |
Anti-patterns avoided
- No standalone scripts/CLIs/Postman for the test values — pushes fire from production code paths
(
ChannexSyncServicevia the SQS consumer) triggered by real inventory/rate changes. - No full-sync polling on a timer — the drift job is nightly and opt-in, not a short interval.
- No per-date API calls — values are range-compressed and batched.
- No hardcoded UUIDs/test values — all ids come from the mapping tables and per-channel config.
- Integration logic lives in the main codebase, not in test files.
Durability
The SQS consumer is a batch listener that acks only after a successful push; an instance crash mid-push leaves messages un-acked for SQS redelivery, so no ARI change is lost. Inbound bookings are the same: a revision is acked only after it is stored, and the feed poll backstops missed webhooks.
Capabilities to declare (Extra Notes)
| Question | Answer |
|---|---|
| Min Stay Through / Arrival | Arrival only (min_stay_arrival) |
| Supported restrictions | rate, min_stay_arrival, max_stay, stop_sell |
| Unsupported restrictions | closed_to_arrival / closed_to_departure (not modelled in the PMS yet) |
| Multiple room types / rate plans | Multiple room types per property; one primary rate plan per room type today |
| Credit-card requirement | Bookings are ingested without card data; no PCI vault in this integration |