DIESER SCHREIBWEG EXISTIERT WEGEN EINES EINZIGEN ANWENDUNGSFALLS: der Wirt führt seinen Urlaub in einem Kalender oder in der Personalplanung, vergisst ihn in TacticTable — und die Buchungsstrecke nimmt Reservierungen für einen geschlossenen Tag an. Alle anderen Konfigurationsschreibwege (Öffnungszeiten, Bereiche, Tische, Speisekarte) bleiben bewusst draussen: sie verdoppeln die Schreibfläche, und ihre Automatisierung ist kein dringender Bedarf.
VIER ARTEN, EINE LISTE. `day` sperrt einen Tag ganz oder von einer Uhrzeit bis zu einer anderen. `timeSlot` sperrt ein Zeitfenster. `partySize` sperrt einen Personenzahlbereich (etwa Gruppen ab acht am Silvesterabend). `area` sperrt einen Bereich für einen Tag. Technisch sind das vier Tabellen — für den Aufrufer ist es EIN Begriff, und deshalb eine Liste mit einem Zeiger.
DIE KENNUNG TRÄGT DIE ART ALS PRÄFIX: `day_…`, `slot_…`, `party_…`, `area_…`. So weiss `DELETE /api/v1/blocks/{blockId}`, welche Tabelle gemeint ist, ohne dass Sie die Art als zweiten Parameter mitführen müssen. Ein unbekanntes Präfix, eine fremde und eine erfundene Kennung ergeben ALLE 404 — aus dem Unterschied liesse sich sonst ablesen, welche Zeilen es gibt.
`date` IST EIN KALENDERTAG UND WIRD HART GEPRÜFT. `"2026-12-24T00:00:00.000Z"` wird ABGELEHNT und nicht auf zehn Zeichen gekürzt. Genau diese Nachsicht hat die Sperren-Seite im Dashboard schon einmal gekostet: die Oberfläche schickte einen Zeitstempel, jemand schnitt ihn ab, und östlich von Greenwich war der gesperrte Tag der falsche. Auch `2026-02-30` wird abgewiesen — den Tag gibt es nicht, und `new Date()` rollte ihn still auf den 2. März weiter.
DIE ANTWORT NENNT `affectedReservations`. Das ist die Zahl der lebenden Reservierungen (`PENDING`, `CONFIRMED`, `OPTION`), die an diesem Tag bereits stehen. Ein Kalenderabgleich, der aus einem falsch benannten Termin den 24. Dezember sperrt, bekommt so „47 betroffen" zurück und kann Alarm schlagen — statt still den Online-Verkauf abzuschalten. Es ist NUR die Zahl, nie eine Zeile: der Schlüssel steht hier auf `tables:write`, nicht auf `reservations:read`.
`Idempotency-Key` IST BEIM ANLEGEN PFLICHT. Ohne ihn erzeugt ein Netzwiederholversuch eine zweite Sperre; die ist fachlich harmlos, aber der Abgleich sieht beim nächsten Lauf eine Zeile, die er nicht kennt, und legt eine dritte an.
DAS LÖSCHEN IST DIE EINZIGE LÖSCHOPERATION DER GANZEN API. Alles andere wird umgestuft (Reservierungen über den Status) oder anonymisiert (Gäste). Eine Sperre ist klein, eindeutig und jederzeit neu anlegbar — und der Kalenderabgleich braucht sie, weil ein gelöschter Kalendereintrag sonst eine Sperre hinterliesse, die nie wieder verschwindet. Beim Löschen ist der Idempotenzschlüssel freiwillig, aber nützlich: ohne ihn beantwortet die zweite Zustellung ein 404, und ein Abgleich protokolliert eine Störung, die keine war.
ES GIBT KEIN `updatedSince`. Keines der vier Modelle hat eine Änderungsspalte, und eine der vier nicht einmal eine Anlagespalte — ein Zeitfilter würde die Bereichssperren stillschweigend unterschlagen. Sperren sind unveränderlich (anlegen und löschen, kein Ändern); der Abgleich liest sein Zeitfenster über `from`/`to` schlicht neu.