API — Hotels & availability (tenant-scoped engine)
This is the same search + book path as the public site: the engine uses TenantVendorConfigService to restrict which distribution vendors (Hotelbeds, Bonotel, Amadeus, etc.) are queried. If a tenant is configured in admin with only bonotel, availability search will only use Bonotel—identical to the web UI.
Always send tenant context on stateless clients:
tenant_id(query or JSON), ortenant(slug, numeric id, ortenants.domain), or- header
X-Tenant(same astenant), or - rely on the Host if it matches
tenants.domainfor a single branded domain.
Accept: application/json on all requests.
1. Capabilities (discovery)
| Method | GET |
| Path | /api/v1/tenant/capabilities |
| Auth | None |
| Query | tenant_id or tenant or X-Tenant; optional market=US (ISO-3166 alpha-2) to evaluate market allow/restrict on configs |
Response (200): data.hotel.vendors_effective lists vendor codes the availability layer will use for that tenant, plus data.enabled_products (UI tabs) and optional data.hotel.vendor_config_rows.
2. Availability search (primary — use for rate shopping)
| Method | POST |
| Path | /api/v1/availability/search |
| Auth | None (or Bearer if you also pass user context) |
Request (JSON) — key fields
| Field | Required | Description |
|---|---|---|
checkIn, checkOut |
Yes | Y-m-d |
tenant_id or X-Tenant / tenant |
Recommended | Resolve tenant; otherwise host/default |
One of: hotelCanonicalCode / hotelCode — or latitude+longitude — or destinationCode — or cityName+countryName |
Yes* | *At least one search mode |
Optional: adults, children, childrenAges, currency, language, roomQuantity / rooms, deduplicate, applyPricing, Amadeus filters, etc. (unchanged from legacy /api/availability/search).
Behaviour: Vendors are filtered to the tenant’s allow list before parallel search, matching admin B2B vendor configuration.
Legacy path (identical handler): POST /api/availability/search
3. Check rate
| Method | POST |
| Path | /api/v1/bookings/check-rate |
| Auth | As needed for your integration |
Legacy: POST /api/bookings/check-rate
4. Create booking
| Method | POST |
| Path | /api/v1/bookings |
| Auth | Varies; supports X-API-Key (tenant’s api_key when configured) plus tenant resolution (BookingController::getTenant) |
Legacy: POST /api/bookings
5. Booking details & voucher
| Method | GET |
| Path | /api/v1/bookings/{vendorBookingCode} |
/api/v1/bookings/{vendorBookingCode}/voucher |
6. Hotel catalog (static / content)
GET /api/v1/hotels, GET /api/v1/hotels/{code} — list/detail helpers; not the multi-vendor availability engine. For prices and inventory aligned with the tenant, use §2 above.
7. Reference data (v1 prefix)
GET /api/v1/refs/places, refs/destinations, refs/cities/search, refs/hotels/autocomplete, etc. (same as /api/refs/...).
Implementation: App\Http\Controllers\Api\AvailabilityController, App\Services\Hotel\AvailabilityService, App\Services\B2B\TenantVendorConfigService.