The posted slot is never trusted
The calendar a shopper sees is built from the shop’s hours, its lead times, its deadlines and its remaining capacity. Then the shopper picks one and posts it back.
The server regenerates the whole calendar and checks the posted slot is in it before recording anything.
That sounds redundant — the browser only had the slots we gave it. But the value comes back from a browser, and a browser is free to send anything. A window applied only when drawing the calendar is a suggestion, not a rule.
It does not stop a determined shopper editing their own checkout’s custom fields; Wix allows the checkout’s owner to do that. What it guarantees is that the bookings collection — the thing the shop actually works from, the list they print at six in the morning — only ever contains real slots.
The same reasoning applies to everything else the calendar encodes. Lead times, weekly deadlines and capacity caps are all rechecked on save. A basket whose notice period exceeds its own booking window offers no dates at all rather than throwing, and that case is detected explicitly so it can be reported as the configuration mistake it is instead of looking like an outage.
The general shape is one every form eventually teaches you: the client’s job is to make the right thing easy, and the server’s job is to make the wrong thing impossible. They are different jobs, and doing the first well does not do the second at all.