Availability

GET /v1/availability answers one question: can this resource take this party, for this date range? It’s a pure read — it never creates or holds anything.

GET /v1/availability?resource_id=<id>&from=<ISO datetime>&to=<ISO datetime>&party_size=<n>

The response is a boolean plus reasons:

{
  "resourceId": "<id>",
  "from": "2026-08-01T00:00:00Z",
  "to": "2026-08-04T00:00:00Z",
  "partySize": 2,
  "available": false,
  "reasons": ["min_stay", "closed_to_arrival"]
}

Reason codes

Code	Meaning
occupancy_exceeded	party_size is over the resource’s capacity
reserved	Another hold or confirmed booking overlaps this window
external_block	Blocked by a synced external calendar (OTA)
min_stay / max_stay	The stay length breaks a rate plan’s night limits
closed_to_arrival / closed_to_departure	The rate plan doesn’t allow check-in or check-out that day
stop_sell	The operator has manually closed this date range

available can be false with several reasons at once — show all of them to the guest, not just the first one your code happens to check.

This same reason vocabulary reappears on POST /v1/quotes’s 409 unavailable response — see Quotes. The two surfaces share one source of truth, so a date that’s unavailable here is unavailable there too; you never need to reconcile two different reason lists.

Both sk_ and pk_ keys can call this endpoint.