Changelog

2026-09 — Three doors, and the rest of the product

• Landlord API at /partner/v1/landlord — a landlord’s own door: their units with tenures, anonymised occupancy, blocks for own use, statement, payouts, invoices, running costs (read and record), released documents with download, and the conversation with the office. Keys are created in the landlord portal (or by the agency on their behalf) and are bound to one landlord. Own contract at /partner/v1/landlord/openapi.json; see the reference.
• Cleaning API at /partner/v1/cleaning — a cleaning company’s own door: the crew’s units, derived jobs with windows and deadlines, the day route, and start/finish/reopen reports that land exactly where the cleaning portal’s taps land. Keys are created in the cleaning portal and are bound to one crew. Own contract at /partner/v1/cleaning/openapi.json; see the reference.
• Doors are enforced: a key belongs to one audience and answers 403 AUDIENCE_MISMATCH anywhere else. GET …/me on every door says which audience a key is and whom it is bound to. The agency console lists and can revoke every key of every door.
• Agency door, second wave — the entities the product grew since the first release, each behind its own scope: GET /requests (enquiries, read:requests), GET/POST/PATCH /tasks (read:tasks, write:tasks), GET /invoices, /payments, /deposits (read:finance), GET /housekeeping/jobs and /teams (read:housekeeping), GET /landlords, /landlords/:id, /landlords/:id/statement (read:landlords), GET /unit-costs and /cost-categories (read:costs), GET /rates and GET /promotions (read:rates), GET /amenities (read:units).
• Units carry what the product now knows: beds, bedroomDetails (sleeping arrangement), tourUrl (3D tour), permitNumber / permitUrl, petsAllowed, coordinates, photos and a coverPhoto, and per-unit amenities on the detail — all additive.
• Bookings now also return sourceRef, currency, earlyCheckin, lateCheckout, holdUntil and createdAt. sourceRef was promised on reads since the write path shipped and was missing — fixed.
• Guests carry stage (prospect / customer), presales and convertedAt; GET /guests?stage=prospect lists presales conversations.
• Personal data keeps one line: the contact block on enquiries and the buyer block on invoices appear only when the key also holds read:guests.
• New page What is covered: every entity of the product, which door exposes it, and what is left out on purpose.
• The explorer takes ?spec=agency|landlord|cleaning.

2026-08 — A machine-readable contract

• GET /partner/v1/openapi.json — the full surface as OpenAPI 3.1, generated from the route definitions rather than written alongside them, so it cannot drift from what the API actually serves. Readable without a key; point your client generator at it.
• Interactive explorer — every endpoint with its schemas, and a request runner that uses your own key.
• Validation errors now name the offending field in their title. The code is unchanged at VALIDATION, which is what you branch on.

2026-08 — Webhooks

• Bookings can be pushed to you instead of polled: booking.created, booking.updated, booking.cancelled. The agency registers endpoints in its portal; see the webhooks guide.
• Every request is signed with HMAC-SHA-256 over <timestamp>.<body> in an X-MyRentalCalendar-Signature header, with a per-endpoint secret.
• Failed deliveries retry after 1 min, 5 min, 30 min, 2 h and 6 h; an endpoint failing 20 times in a row is switched off and the agency is shown why.
• Payloads carry no guest personal data, whatever the key’s scopes — the body travels to a URL the platform does not control.

2026-08 — Writing bookings, and reading guests

• write:bookings — new scope. POST /partner/v1/bookings creates a booking, POST /partner/v1/bookings/:id/cancel cancels one. Both run the same checks as the agency’s own portal (minimum stay, cleaning block, expected extensions, double-booking guard) and neither accepts a price: the engine decides. See the guide.
• read:guests — new scope for guest master data (name, contact, nationality, stay references). Identity documents captured at check-in remain unavailable through the API, in both directions.
• Both new scopes are off by default when a key is created, and existing keys did not gain them.
• GET /partner/v1/bookings/:id and GET /partner/v1/fee-types added.
• Lists paginate: ?page=&pageSize= with totalItems / pageCount beside the collection. limit keeps working, and bookings is still the array’s name — nothing existing had to change.
• Writes are recorded in the agency’s audit trail with the key as the actor.

2026-08 — Budgets per key, and a visible month

• The per-minute budget now follows the key, not the client address, and it is 60/minute rather than 120 per address. Several integrations behind one office IP no longer share one budget, and a runaway script cannot starve its siblings. Splitting work across two keys buys throughput.
• X-RateLimit-Limit / -Remaining / -Reset on every answer, so you can pace instead of waiting to be refused.
• Monthly quota of 50,000 requests per agency across all keys, answering 429 QUOTA_EXCEEDED with quota, used and resetsAt. The position is on GET /partner/v1/me and in the agency portal.
• CORS is now open on /partner/* and /mcp (Access-Control-Allow-Origin: *). The surface takes no cookies, so browsers may call it directly — which still does not make shipping a key to a browser a good idea.

2026-08 — Key introspection & self-service keys

• GET /partner/v1/me — new. Returns the agency behind the key, the key’s scopes and the enforced rate budget. No scope required.
• Key management moved into the portal (Partner API page): create keys with per-scope selection and optional expiry, see last use, revoke instantly. Previously keys existed only via the internal API.
• Managing keys is now its own functional right, so it can be delegated without handing out an admin login. Revoking a key keeps working after a downgrade.

2026-08 — Initial release

• Partner REST API /partner/v1 (read-only): units, availability, live quotes, bookings.
• MCP server at /mcp — Streamable HTTP, stateless; tools list_units, get_availability, quote_stay, list_bookings.
• Self-service API keys with scopes, optional expiry, instant revocation and last-used tracking (portal → Settings → API keys, Pro plan).
• Rate limit 120 requests/minute per client across REST and MCP.

Additive changes land here without notice periods; breaking changes ship as /partner/v2 with a migration window.