party_size : размер вечеринки, который может быть размещен в течение этого временного интервала. Ресторан может быть связан с несколькими слотами одновременно, в каждом из которых указан разный party_size , если, например, при резервировании могут разместиться 2, 3 или 4 человека.
spots_open : количество мест, доступных в настоящее время для этой записи о доступности.
spots_total : общее количество мест, которые есть у продавца для этой конфигурации (включая те, которые недоступны).
Эти три параметра работают вместе, чтобы создать цифровое представление плана этажа. party_size — это количество человек, которое может вместить каждый стол (для каждого размера стола будет своя запись). spots_open и spots_total — это количество столов, которые могут вместить этот party_size .
Пример пустого плана этажа
Представьте себе ресторан со следующей планировкой и без активных заказов:
Рисунок 1. План этажа без активных бронирований.
Значения party_size , spots_open и spots_total будут следующими:
party_size
пятна_открыть
пятна_всего
4
3
3
5
3
3
6
4
4
7
1
1
8
1
1
Фид доступности для одного временного интервала у этого продавца будет выглядеть так:
Указание доступности столовой с поддержкой комбинированных столов
Есть много способов, которыми ресторан может объединить столы для обслуживания больших групп. Ожидается, что в ваших фидах вы укажете spots_open и spots_total таким образом, чтобы точно отражать, можете ли вы принимать вечеринки заданного размера. Ниже приведен один из примеров того, как можно указать объединение таблиц. Ваши каналы могут несколько отличаться в том, как производится этот расчет, и вы можете указать spots_open и spots_total способом, соответствующим вашей бизнес-логике.
Если ресторан поддерживает объединение столов в большую вечеринку, вы можете обновить spots_open и spots_total чтобы отразить это.
Скажем, в ресторане можно объединить два небольших столика, чтобы вместить группу из 7–10 человек.
Рисунок 3. План этажа без активных бронирований.
В случае отсутствия активных бронирований значения party_size , spots_open и spots_total будут следующими:
party_size
пятна_открыть
пятна_всего
4
3
3
5
3
3
6
4
4
7
1
1
8
1
1
9
1
1
10
1
1
Теперь, при той же планировке, делается заказ на вечеринку из 10 человек, состоящую из двух небольших столиков.
Рисунок 4. План этажа с одним активным бронированием, охватывающим два стола.
Затем значения party_size , spots_open и spots_total теперь будут такими:
[null,null,["Последнее обновление: 2025-07-25 UTC."],[[["\u003cp\u003e\u003ccode\u003eparty_size\u003c/code\u003e, \u003ccode\u003espots_open\u003c/code\u003e, and \u003ccode\u003espots_total\u003c/code\u003e are key parameters in the Availability feed that represent a restaurant's floor plan and seating capacity.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003espots_open\u003c/code\u003e and \u003ccode\u003espots_total\u003c/code\u003e are dynamic values that reflect real-time availability, decreasing as bookings are made and tables are occupied.\u003c/p\u003e\n"],["\u003cp\u003eRestaurants can utilize these parameters to indicate support for combining tables for larger parties, adjusting \u003ccode\u003espots_open\u003c/code\u003e and \u003ccode\u003espots_total\u003c/code\u003e accordingly.\u003c/p\u003e\n"],["\u003cp\u003eThe provided JSON examples demonstrate how the Availability feed is structured and how these parameters are used to represent different booking scenarios.\u003c/p\u003e\n"],["\u003cp\u003eMerchants can adapt their feed logic to align with their specific business rules for managing table availability and combinations.\u003c/p\u003e\n"]]],["The core content details how `party_size`, `spots_open`, and `spots_total` define restaurant availability. `Party_size` indicates the capacity per table. `Spots_open` represents the currently available spots, while `spots_total` is the total spots a merchant has. Restaurants can have multiple slots for the same time, each with varying `party_size`. Examples illustrate floor plan representation both with and without bookings, showing how `spots_open` decreases as bookings are made and how table combination support is handled.\n"],null,["# Structuring availability data for Reservations\n\nParameter definitions\n---------------------\n\nAs specified in the\n[`Availability`](/actions-center/verticals/reservations/e2e/reference/feeds/availability-feed#Availability-definition)\ndefinition:\n\n- `party_size`: The party size that can be accommodated during this time slot. A restaurant can be associated with multiple Slots for the same time, each specifying a different `party_size`, if for instance 2, 3, or 4 people can be seated with a reservation\n- `spots_open`: The number of spots currently available for this availability entry\n- `spots_total`: The total number of spots that the merchant has for this configuration (including those that are not available)\n\nThese three parameters work together to build a digital representation of the\nfloor plan. `party_size` is the number of people each table can hold (there will\nbe an entry for every size a table can accommodate). `spots_open` and `spots_total`\nare counts of how many tables can accommodate that `party_size`.\n\nExample empty floor plan\n------------------------\n\nImagine a restaurant with the following floor plan and no active\nbookings:\n**Figure 1:** Floor plan with no active bookings\n\nThe values for `party_size`, `spots_open`, and `spots_total` would be:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 3 | 3 |\n| 5 | 3 | 3 |\n| 6 | 4 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n\nThe availability feed for one time slot at this merchant would look like: \n\n### JSON\n\n```json\n{\n \"availability\": [\n {\n \"spots_total\": 3,\n \"spots_open\": 3,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 4\n }\n },\n {\n \"spots_total\": 3,\n \"spots_open\": 3,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 5\n }\n },\n {\n \"spots_total\": 4,\n \"spots_open\": 4,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 6\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 7\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 8\n }\n }\n ]\n}\n```\n\nExample floor plan with a booking\n---------------------------------\n\nNow imagine that one of the round tables was booked:\n**Figure 2:** Floor plan with one active booking\n\nThe values for `party_size`, `spots_open`, and `spots_total` would now be:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 2 | 3 |\n| 5 | 2 | 3 |\n| 6 | 3 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n\n### JSON\n\n```json\n{\n \"availability\": [\n {\n \"spots_total\": 3,\n \"spots_open\": 2,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 4\n }\n },\n {\n \"spots_total\": 3,\n \"spots_open\": 2,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 5\n }\n },\n {\n \"spots_total\": 4,\n \"spots_open\": 3,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 6\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 7\n }\n },\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1535806800,\n \"merchant_id\": \"merch1\",\n \"resources\": {\n \"party_size\": 8\n }\n }\n ]\n}\n```\n\nSpecifying dining availability with combined tables support\n-----------------------------------------------------------\n\nThere are many ways that a restaurant could combine tables to support larger\ngroups. You are expected in your feeds to specify `spots_open` and `spots_total`\nin a way that accurately reflects whether you can accept parties of a given\nsize. What follows is one example of how you can specify combining tables.\nYour feeds may differ somewhat in how this calculation is made and it is\nacceptable for you to specify `spots_open` and `spots_total` in a way that\nmatches your business logic.\n\nIf a restaurant supports combining tables to form a larger party, you can\nupdate your `spots_open` and `spots_total` to reflect this.\n\nSay a restaurant can combine two small tables to seat a party of 7-10\npeople.\n**Figure 3:** Floor plan with no active bookings\n\nIn the case of no active bookings, the values for `party_size`, `spots_open`,\nand `spots_total` are:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 3 | 3 |\n| 5 | 3 | 3 |\n| 6 | 4 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n| 9 | 1 | 1 |\n| 10 | 1 | 1 |\n\nNow, with the same floor plan, a booking is made for a party size of 10 that\ncombines two small tables.\n**Figure 4:** Floor plan with one active booking spanning two tables\n\nThen, the values for `party_size`, `spots_open`, and `spots_total` are now:\n\n| party_size | spots_open | spots_total |\n|------------|------------|-------------|\n| 4 | 1 | 3 |\n| 5 | 1 | 3 |\n| 6 | 2 | 4 |\n| 7 | 1 | 1 |\n| 8 | 1 | 1 |\n| 9 | 0 | 1 |\n| 10 | 0 | 1 |"]]