Where custom fields go: three regions. A custom field is placed in one of three named regions of the booking form, not after an arbitrary field. This is what keeps a customer's configuration working when the default form changes.

• contact — under the patient's email and phone.
• insurance — under the insurance questions.
• end — last, just above the buttons.

The two canvases below write the anchors "after": "custom_fields_after_patient_details" (contact) and "after": "custom_fields_after_insurance" (insurance), which the live scheduler and the new one both understand. The new scheduler also accepts "region": "contact" / "insurance" / "end", but the live one ignores those, so don't hand-write them until it ships. after/before naming any other default field snaps to whichever region that field lives in. removeFieldIds and modifyFields are unchanged.

Testing a configuration without booking. The widget posts to the live booking endpoint in every build, so a test page must set window.GSP_DRY_RUN = true before the scheduler.js script tag. The submit is then logged to the console and nothing is booked. Every page under public/testing/ does this.