Tables & Floors

This group of endpoints describes the physical structure of a restaurant: floors, areas, tables and their current state on the floor (free/occupied/reserved). A partner needs it to read the seating map, learn table capacities and real-time states, and to build a floor plan.

All endpoints require a Bearer token (see Authentication). Base path for table management: /api/tm/admin/restaurants/{restaurantId}.

A note on terms. In Hostme a “floor” is a separate seating map: it has a floorId, a name and an optional background map. An “area” is a text grouping of tables within a floor (e.g. “Outdoor Seating”, “By the window”). A table has an area field and a link to its floor.

List of tables

GET /tables

Returns all the restaurant’s tables with their capacity, area, tags and availability rules (for reservations and for the waitlist). This is the main table directory for a partner integration.

Key table fields (TableContract)

Availability object (TableAvailabilityContract)

Same structure for reservability and waitability:

Each hours element contains weekDay (weekday number) and an array of time intervals with open / close fields (date-span format, time since midnight) and an optional name.

Example

curl -G https://api.hostmeapp.com/api/tm/admin/restaurants/123/tables \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "includeEvents=false"

Summary by area

GET /floorareas

Returns aggregated statistics for each area within each floor: how many tables and seats in total, and how many of them are available online. Handy for capacity dashboards.

Response fields (FloorAreaContract)

curl https://api.hostmeapp.com/api/tm/admin/restaurants/123/floorareas \
  -H "Authorization: Bearer $TOKEN"

List of floors

GET /floors

Returns the restaurant’s floors with table and seat aggregates. The includeOffline and includeEvents parameters control whether offline floors and event floors are included.

Response fields (FloorInfoContract)

curl -G https://api.hostmeapp.com/api/tm/admin/restaurants/123/floors \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "includeOffline=false"

One floor

GET /floors/{floorId}

Returns the data of a specific floor by floorId (name, map/plan, offline flag). Use it to load the floor’s background layout.

The exact schema of the success response (200) is not fixed in the specification. For the floor structure, refer to FloorContract (see “Floor management” below): floorId, name, map, floorUrl, isOffline.

Real-time table state

GET /tables/monitors

Returns a “snapshot” of the floor: whether the restaurant is open and the current state of each table (free, occupied, reserved, etc.), including the attached guest, servers and seating timings. This is the main endpoint for rendering a live floor map.

Response structure (RestaurantState)

Table monitor fields (TableMonitorContract)

Table statuses (TableStatus)

The status field is an integer enum with values 0…4. The exact labels for the numbers are not fixed in the specification; treat the text state field as the human-readable state and use status as a stable machine code. Don’t hard-code the meaning of the numbers — check against state.

curl -G https://api.hostmeapp.com/api/tm/admin/restaurants/123/tables/monitors \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "Time=2026-07-01T19:00:00" \
  --data-urlencode "WithNextSlot=true"

Occupancy timeline

GET /tables/timeline

Returns snapshots of the floor state through the day — for building a timeline of table load. Besides the state of each table, it includes guest aggregates (seated, waiting, reserved) and turnover progress bars.

Response structure (FloorStateTimeline)

Each FloorTablesSnapshot contains the time (dateTime, timestamp, shiftDate), aggregates (tablesCount, busyTablesCount, groupTotalMembers, seatedMembersCount, reservationMembersCount, waitingMembersCount) and a monitors array (TableTimelineContract) with the same set of statuses/timings as in /tables/monitors, plus table (tableProgressBar) and card (cardProgressBar) progress bars.

curl -G https://api.hostmeapp.com/api/tm/admin/restaurants/123/tables/timeline \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "Date=2026-07-01"

A timeline recalculation can be triggered manually: POST /tables/timeline/recalculate (no body).

Table settings

GET /tables/settings

Returns the table combination and blocking rules. These settings affect how the system picks tables for a booking. Read — GET, change — PUT with a TablesSettingsContract body.

Settings fields (TablesSettingsContract, for PUT)

curl https://api.hostmeapp.com/api/tm/admin/restaurants/123/tables/settings \
  -H "Authorization: Bearer $TOKEN"

Change table state

PUT /tables/state

Changes the state of a booking/seating at a table (e.g. move a guest to “seated”, “finished”, etc.). Body — ChangeTableStateContract.

Response — the updated booking (BookingContract) with the current status and timings.

curl -X PUT https://api.hostmeapp.com/api/tm/admin/restaurants/123/tables/state \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "bookingId": "ABC_ID", "state": "Seated" }'

Releasing a table. There are separate PUT /tables/{bookingId}/release (release a table by booking) and POST /tables/release (bulk release). Seating / assigning a table to a booking — via PUT /seat/{registrationId} (body RegisterAtTableContract). These operations belong to the host’s work on the floor; see also Reservations.

Floor management (CRUD) — overview

Creating, editing and deleting floors. A partner rarely needs these operations (the structure is usually maintained by restaurant staff), so here is a brief overview.

Create/edit body — FloorContract:

curl -X POST https://api.hostmeapp.com/api/tm/admin/restaurants/123/floors \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Terrace", "isOffline": false }'

GET /merge?ids=... is also available — a service operation for merging tables; not required for a typical partner integration.

Floor plan from a photo

POST /floor-plan/image

Accepts a photo of a floor plan (a downscaled JPEG, ≤1024px on the long side, Base64-encoded) and returns a generated plan in PlanDSL format (JSON). Recognition is done by a two-pass Gemini 2.5 Flash vision model with an automatic fallback provider (OpenRouter) when the quota is exhausted. Path: /api/restaurants/{restaurantId}/floor-plan/image.

Request body (FloorPlanFromImageRequest)

Response (FloorPlanFromImageResponse)

curl -X POST https://api.hostmeapp.com/api/restaurants/123/floor-plan/image \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "imageBase64": "/9j/4AAQSkZJRg...", "contentType": "image/jpeg" }'

The client downscales the image to ≤1024px itself before sending. The returned planDSL can be saved to the floor’s map field (FloorContract).

General rules (headers, ProblemDetails error format, response codes) — in Conventions and Errors. The lifecycle of bookings at tables — in Reservations.