The slot is stored twice, deliberately
A chosen collection slot is written to two places, and the duplication is not an oversight.
It goes on the checkout’s custom fields, so it appears on the order where a shop expects to find it — in the order detail, in the email, wherever they already look.
And it goes into a bookings collection, because custom fields are not queryable. The dashboard needs to sort by collection date, filter to a day, and count how many orders a week already holds. None of that is possible against a custom field.
Storing the same fact twice is usually a mistake, so it is worth being clear which copy is authoritative. The booking is. The dashboard’s lists and the weekly capacity counts read from it, and it is always right.
The order keeps whatever the customer chose at checkout — and here is the awkward part. It cannot be updated afterwards. The update call accepts a short, explicit list of fields: buyer email, language, weight unit, billing and recipient details, archived, attribution source, seen-by-a-human. Custom fields are not among them. This is not a permission we are missing; the API does not take the field.
That was tested rather than assumed. A function writes it, reads the order back, and reports what survived. On a real order, nothing does — Wix accepts the call and stores none of it.
So a collection that moves after the order exists lives in two states: the booking, which is correct, and the order, which shows the original time with a merchant comment on its timeline recording the change. The customer’s confirmation email likewise keeps the original.
Which means a shop moving a collection still has to tell the customer. Nothing here does it for them, and the documentation says so plainly rather than letting someone assume otherwise.