generated: '2026-08-22' method: derived source: >- openapi/guestready-rentalready-openapi.yml (verbatim from https://pms.rentalready.io/api/v3/schema/), https://github.com/guestready/rentalready-api-client-examples, https://support.rentalready.com/hc/en-us api: RentalReady API standards: - id: oauth2 name: OAuth 2.0 (RFC 6749) conforms: true evidence: >- components.securitySchemes.oauth2 declares an authorizationCode flow with authorizationUrl /o/authorize/, tokenUrl /o/token/ and refreshUrl /o/token/, and 54 named scopes. The provider's own client-examples repository documents the full code -> refresh-token exchange with grant_type=authorization_code, and the endpoints are the Django OAuth Toolkit /o/ mount, live at https://pms.rentalready.io/o/authorize/ (HTTP 200). - id: oauth2-refresh-token name: OAuth 2.0 refresh token grant conforms: true evidence: refreshUrl declared on the flow; python/main.py in the examples repo persists and rotates the refresh token - id: oidc name: OpenID Connect conforms: false evidence: no openIdConnect security scheme; /.well-known/openid-configuration returns 404 on every host - id: rfc9457 name: Problem Details for HTTP APIs (RFC 9457 / RFC 7807) conforms: false evidence: >- no application/problem+json media type anywhere in the spec; the four declared error envelopes are Django REST Framework shapes ({"detail":...}, {"message":...}, field arrays, non_field_errors) — see errors/guestready-problem-types.yml - id: pagination name: Consistent collection pagination conforms: true evidence: >- 63 collection operations expose limit + offset with a Paginated*List envelope (count/next/previous/results/limit); three expose a cursor parameter instead - id: idempotency name: Idempotency keys on unsafe methods conforms: false evidence: no Idempotency-Key header or equivalent parameter on any of the 252 operations - id: rate-limit-headers name: RateLimit header fields (RFC 9239 draft / X-RateLimit-*) conforms: false evidence: >- a 400 requests/minute throttle is stated in info.description but no 429 response, Retry-After or RateLimit-* header is declared on any operation - id: rest name: Resource-oriented REST over HTTP/JSON conforms: true evidence: 252 operations across 162 paths, GET/POST/PUT/PATCH/DELETE, application/json on 242 responses - id: openapi name: OpenAPI 3.0.3 conforms: true evidence: >- openapi 3.0.3 served anonymously at https://pms.rentalready.io/api/v3/schema/ (YAML) and ?format=json (JSON), generated by drf-spectacular; 252 unique operationIds, 296 component schemas - id: mutual-tls name: Mutual TLS client authentication conforms: false evidence: no mutualTLS security scheme - id: hsts name: HTTP Strict Transport Security conforms: false evidence: probed 2026-08-22 — no Strict-Transport-Security header on www.guestready.com or pms.rentalready.io (see security/guestready-domain-security.yml) - id: dnssec name: DNSSEC conforms: false evidence: probed 2026-08-22 — neither guestready.com nor rentalready.io is signed domain_standards: - id: icalendar name: iCalendar (RFC 5545) availability exchange market: short-term / vacation rental distribution conforms: true evidence: >- The contract declares a first-class iCal synchronisation resource, not a prose claim: components.schemas.IcalSync with an `ical_url` property (format: uri, title "ICal Import URL", description "The URL to fetch the iCal calendar from"), `platform_id`, `is_active` and `last_sync`, exposed as a full CRUD surface at /api/v3/icals/ (icals_list, icals_create, icals_retrieve, icals_update, icals_partial_update, icals_destroy) and paginated as components.schemas.PaginatedIcalSyncList. why_it_matters: >- iCal URL exchange is the lowest-common-denominator interoperability standard between short-term rental platforms, channel managers and PMSs. A property manager whose other systems already speak iCal connects a calendar to RentalReady with a URL and no bespoke connector; one whose systems do not needs a bilateral integration. The distinction is a real integration-cost difference for a buyer. spec_location: 'components.schemas.IcalSync ; paths./api/v3/icals/' docs: https://support.rentalready.com/hc/en-us/articles/41553167842961-iCal-Calendar-Synchronization - id: ota-channel-distribution name: OTA channel distribution (Airbnb / Booking.com / Vrbo native APIs) market: short-term / vacation rental distribution conforms: partial evidence: >- /api/v3/listings/, /api/v3/rental_platform_accounts/, /api/v3/rental_platform_settings/ and /api/v3/reservation_platforms/ model per-OTA accounts, listings and overrides (components.schemas.RentalListing, RentalAccount, SynchronizationCategoryEnum, ChannelEnum). note: >- Recorded as `partial` deliberately: these are integrations against each OTA's proprietary API, not an implementation of an open distribution standard. No OpenTravel (OTA/OTC), HTNG or ALP schema, namespace or message type appears anywhere in the contract. This is an honest "the market standard is not what this provider implements", not a conformance claim. - id: none-applicable name: SCIM / OData / OpenRTB / HL7 / X12 / ISO 20022 / ActivityPub / OAI-PMH / LTI conforms: false evidence: >- checked for each — no SCIM schema URN, no $metadata surface, no bid endpoint, no message-type identifiers. None of these standards addresses this provider's market; recorded as checked-and-absent, not as a gap. compliance: certifications_published: [] trust_center: null note: >- No trust center, SOC 2 / ISO 27001 / PCI claim or compliance page was found on any anonymously reachable GuestReady or RentalReady surface (probe-security-programs.py returned vdp=none trust=none on 2026-08-22, and www.rentalready.com is behind a robot challenge). No Compliance pointer is emitted, because no certification is published. The platform does handle regulated data — guest registration (/api/v3/guest_registration/), city tax rules, KYC and rental agreement signatures — which makes the absence of a published compliance posture a notable gap rather than a non-applicable one.