party_size: Bu zaman aralığında kabul edilebilecek parti büyüklüğü. Bir restoran, aynı saat için birden fazla Slot ile ilişkilendirilebilir. Örneğin, rezervasyonla 2, 3 veya 4 kişi oturabiliyorsa her biri farklı bir party_size belirtir.
spots_open: Bu müsaitlik durumu girişi için şu anda mevcut olan yer sayısı
spots_total: Satıcının bu yapılandırma için sahip olduğu toplam yer sayısı (kullanılmayan yerler dahil)
Bu üç parametre birlikte çalışarak kat planının dijital bir temsilini oluşturur. party_size, her masanın sığdırabileceği kişi sayısıdır (bir masanın sığdırabileceği her boyut için bir giriş bulunur). spots_open ve spots_total, bu party_size değerini barındırabilecek masa sayısını belirtir.
Boş kat planı örneği
Aşağıdaki kat planına sahip ve etkin rezervasyonu olmayan bir restoran düşünün:
Şekil 1: Etkin rezervasyonu olmayan kat planı
party_size, spots_open ve spots_total değerleri şu şekilde olur:
party_size
spots_open
spots_total
4
3
3
5
3
3
6
4
4
7
1
1
8
1
1
Bu satıcının bir zaman aralığı için stok durumu feed'i şöyle görünür:
Restoranlar, daha büyük grupları desteklemek için masaları birleştirmenin birçok yolunu kullanabilir. Feed'lerinizde spots_open ve spots_total parametrelerini, belirli bir boyuttaki partileri kabul edip edemeyeceğinizi doğru yansıtacak şekilde belirtmeniz gerekir. Aşağıda, tabloları nasıl birleştireceğinizi belirtebileceğinize dair bir örnek verilmiştir.
Feed'leriniz bu hesaplamanın yapılma şeklinde biraz farklılık gösterebilir ve spots_open ile spots_total değerlerini iş mantığınıza uygun şekilde belirtmeniz kabul edilir.
Bir restoran, daha büyük bir grup oluşturmak için masaların birleştirilmesini destekliyorsa spots_open ve spots_total değerlerini bunu yansıtacak şekilde güncelleyebilirsiniz.
Bir restoranın, 7-10 kişilik bir grup için iki küçük masayı birleştirebileceğini varsayalım.
Şekil 3: Etkin rezervasyonu olmayan kat planı
Etkin rezervasyon yoksa party_size, spots_open ve spots_total değerleri:
party_size
spots_open
spots_total
4
3
3
5
3
3
6
4
4
7
1
1
8
1
1
9
1
1
10
1
1
Şimdi aynı kat planında, iki küçük masanın birleştirildiği 10 kişilik bir grup için rezervasyon yapılıyor.
Şekil 4: İki masaya yayılan bir etkin rezervasyon içeren kat planı
Ardından party_size, spots_open ve spots_total değerleri şu şekilde olur:
[null,null,["Son güncelleme tarihi: 2025-07-26 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 |"]]
