Changelog

What has changed in the Brand Integration API, and what we consider ourselves free to change without telling you first.

Compatibility policy

The API version is stamped on every webhook as version and returned by GET /me. It is currently 2026-09.

Within a version, changes are additive only. Concretely, these may happen without notice:

A new field appears in a response or an event payload.
A new event type appears — you will only receive it if your subscription includes it.
A new optional request field is accepted.
A new error code appears for a case that previously had a more general one.
An error message is reworded. Branch on code, not prose.

These will not happen inside a version:

A field is removed, renamed, or changes type.
An existing field changes meaning.
A previously optional request field becomes required.
An endpoint changes path or method.

Parse defensively

Ignore fields you do not recognise, and never assert on the exact set of keys in a payload. A strict schema that rejects unknown properties will break on an additive change that every other integration absorbs silently.

A breaking change means a new version. Versions run in parallel, and we would agree a migration window with you before anything is switched off.

Releases

`2026-09` — current

The first public release.

Signed webhooks for availability, rates, restrictions, inventory, properties and bookings, plus a connectivity ping. Gap-free per-integration sequencing, full-state payloads, strict in-order delivery.
Booking API: create with mandatory idempotency, retrieve by either id, update with optional If-Match concurrency, and idempotent cancel.
Reconciliation: property listing, availability, rate and restriction snapshots sharing the webhook payload shapes, event replay over a 30-day window, and full re-sync.
HMAC-SHA256 request signing with a 24-hour dual-secret rotation window.

Documentation changes

These clarified the documentation without changing behaviour. They are listed because if you built against an earlier draft, these are the places you may have guessed wrong.

Field	Type	Description
`property.changed` carries `property_type`	clarified	It was always sent, and was missing from the catalogue.
`units[]` carries `code`, `is_default`, `max_occupancy`, `deleted`	clarified	All four were always sent. `deleted` in particular is how you know to retire an alias.
`Accept` and `X-Doorloom-Integration` delivery headers	clarified	Both were always sent and were missing from the header list.
`errors.availability.window.to` is `check_out` minus one day	clarified	It is the last night of the stay, not the departure date.
`Money is a JSON number`	clarified	`13000.00` serialises as `13000`. Parse numerically.
`Timestamps are ISO-8601 in Asia/Kolkata`	clarified	They carry a `+05:30` offset and are not UTC-normalised.
`source.channel` is not patchable	clarified	Only `source.reference` can be changed after create.
`No acknowledge endpoint, no single-event resend`	clarified	The `after_sequence` cursor is the only catch-up mechanism; a redelivery is always a new event.

Behaviour changes

Field	Type	Description
`POST /sync` is limited to one per 24 hours	changed	The interval between full re-syncs was 10 minutes and is now 24 hours; the edge cap moved from six an hour to six a day. Nothing about the response shape changed — a too-soon call is still `429 SYNC_TOO_SOON` with `errors.retry_after`, which now simply reports a much larger number. If you were re-syncing to recover from missed events, move to `GET /events`, which has no interval.
`401` returns the standard envelope	changed	An unauthenticated call now answers an envelope whose `code` is `UNAUTHENTICATED`, instead of a bare `message` object. If you branched on the absence of `code`, branch on the status instead.
`429` returns the standard envelope	changed	A rate-limited call now answers an envelope whose `code` is `RATE_LIMITED`, carrying `errors.retry_after`, instead of a bare `message` object. The `Retry-After` and `X-RateLimit-*` headers are unchanged.

Both were documented as enveloped before they were. They now match the documentation, which means every failure from this API — with the single exception of the platform-level 404 when the API is switched off entirely — carries a code you can branch on.

Staying informed

Doorloom contacts integration partners directly about anything that affects them. If the right person for that is not the person who set up your integration, tell [email protected] who it should be.