Staying in sync

Four situations, four answers. The wrong tool works but costs everyone more, so it is worth knowing which is which.

Which tool

Field	Type	Description
`First connection`	snapshots	Load `GET /properties`, then a snapshot per property per type. Set your cursor from the watermark.
`Outage under 30 days`	replay	`GET /events?after_sequence=`. Cheapest, exact, no interval.
`Cursor older than 30 days`	snapshots	Past retention, replay cannot be complete. Re-load as if cold.
`One property looks wrong`	snapshot	Pull that property and window, compare, correct.
`Everything looks wrong`	sync	`POST /sync`. The blunt instrument.

Cold start

Call GET /properties. Store the id mapping, and note data.sequence.
For each property, pull the three snapshots over the range you sell — availability, rates, restrictions — in windows of at most 92 days.
Set your cursor per property and type from each snapshot's data.sequence.
Start accepting webhooks. Anything numbered above your cursor applies cleanly on top.

Start the webhook endpoint before the backfill, not after

Events that arrive mid-backfill are not a problem — they carry higher sequences than any snapshot you take, so the apply-if-newer rule sorts them out. Turning the endpoint on afterwards leaves a window where changes are simply lost.

After an outage

Compare your cursor with latest_sequence, from either GET /me or any ping. If the gap is inside 30 days, page forward:

python

cursor = load_cursor()

while True:
    r = get("/events", params={"after_sequence": cursor, "limit": 200})
    for row in r["data"]:
        handle(row["event"])            # the same handler your webhook uses
    cursor = r["cursor"]["next_after_sequence"]
    save_cursor(cursor)
    if not r["cursor"]["has_more"]:
        break

Your endpoint may well have been auto-paused. It resumes on its own when it next answers a probe with a 2xx, within 30 minutes, and the backlog then drains in order. You do not have to ask for anything.

Replaying while the backlog drains is safe

Both paths feed the same apply-if-newer rule, so an event you get twice is applied once. There is no need to coordinate the two.

Checking for drift

Drift means your stored state disagrees with Doorloom's despite no error having occurred. It should not happen; check for it anyway, because the cost of not noticing is an overbooking.

A reasonable job: nightly, for each property, pull an availability snapshot over the next 60 days and compare available_units per night against what you hold. Alert on any difference rather than silently correcting, then correct.

Two mismatches that are not drift:

A night you show as sold out and Doorloom shows as available. A checkout hold expired, or a booking was cancelled. Apply the snapshot.
A blocked night with block_scope: "ota_only" that Doorloom still counts as available. That is correct: an OTA-only block does not stop a direct booking. See availability.changed.

Reconciling bookings

The calendar and the bookings are separate concerns. For bookings, poll GET /bookings with updated_since set to the highest updated_at you have processed.

Results are ordered oldest-updated first, so paging forward can never skip a record that changed while you were paging. Compare revision to decide whether you already hold the current version.

What never needs reconciling

Bookings you created are yours; Doorloom does not invent them. Availability arising from your own bookings is already reflected in the events you receive. And a booking created twice by a retried request cannot happen if you send an Idempotency-Key, which is the whole reason it is mandatory.

If none of this fits

Before reaching for POST /sync, write to [email protected]. Doorloom staff can see your delivery history, your dead-lettered events and your incidents, which usually identifies the real cause faster than a re-sync papers over it.