Skip to main content
Seyaha calls POST /availability in two situations:
  1. During catalog sync — for every product × option, with a 60-day lookahead window from today
  2. At checkout — real-time check before placing a hold, to verify the slot is still available and get a fresh availabilityId

Request

Request body


Response

Return an array of availability objects — one per bookable time slot.

Availability object

Status values

Unit pricing object


Full example

If an option has no availability in the requested window, return an empty array:

Implementation notes

availability.id is the most critical field in this response. Seyaha caches it as availability_id on the slot and sends it back in POST /bookings/reserve. If you change this ID for the same physical slot, Seyaha will call POST /availability again at checkout to resolve a fresh one — this adds latency to every checkout. Keep IDs stable.
Include unitPricing if prices vary by date, time, or demand (e.g. peak/off-peak). If all slots for an option have the same price, you can omit unitPricing entirely and Seyaha falls back to the static pricingFrom on the option’s units.
  • Timeout: 20 seconds — the longest Seyaha allows. Aim to respond within 15 seconds.
  • During sync, Seyaha calls this for every option of every product. For 100 products × 3 options = 300 calls per sync. Use efficient database queries or a pre-computed availability table.
  • Return [] for options with no availability — not a 404 or error.