Sync availability out

When a booking lands on any channel, StayBind recomputes the affected unit's availability and pushes the change out to every connected channel, including yours. This is what keeps your OTA from selling a night that's already gone.

The push path

Ledger changes        coalesce by          POST /availability      your calendar
(a booking      ──▶   unit + date    ──▶   to your OTA        ──▶   mirrors the
 anywhere)            range                                         ledger

• Delta pushes are the primary path. A ledger change enqueues a targeted push of just the affected dates to your POST /availability (and POST /rates / POST /restrictions when those change). Bursts for the same unit are coalesced into one call.
• A nightly full sync re-pushes the whole forward horizon for each unit, correcting any drift if a delta push was ever missed. You don't have to do anything to benefit from it.
• Rate limiting keeps outbound calls within a safe budget per account, so a busy operator never floods your API.

What you receive

The bodies are exactly the ones documented in Expose your API:

{ "updates": [ { "unitId": "unit_courtyard", "date": "2026-02-20", "available": 0 } ] }

available is the sellable count for that unit on that date. 0 means the night is taken (block it); a positive number means it's open.

Apply updates idempotently

Treat every push as an upsert keyed by (unit, date) (and (rate plan, date) for rates/restrictions). The latest value for a date wins. Because delta pushes, the reconcile pull, and the nightly full sync can all touch the same date, applying them as upserts (never as increments) keeps your calendar correct no matter the order or how many times a value arrives.

End-to-end

With both directions wired, your OTA is a first-class channel:

1. A guest books on your OTA → you post it to the webhook → the ledger blocks those dates → StayBind pushes the block to every other channel.
2. A guest books on another channel → the ledger blocks those dates → StayBind pushes the block to you.

Either way, the same night can never be sold twice. That's the whole point of one ledger.

See the canonical model for the exact field definitions, and errors & reliability for retry and idempotency rules.