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.

curl

curl "https://api.<domain>/v1/availability?resource_id=<id>&from=2026-08-01T00:00:00Z&to=2026-08-04T00:00:00Z&party_size=2" \
  -H "Authorization: Bearer sk_test_..."

TypeScript

const { data, error } = await client.GET("/v1/availability", {
  params: {
    query: {
      resource_id: "<id>",
      from: "2026-08-01T00:00:00Z",
      to: "2026-08-04T00:00:00Z",
      party_size: 2,
    },
  },
});
if (error) throw error;

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

Tip

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.