- Shipped
- 5 ஆகஸ்ட், 2026 அன்று 5:41 PM UTC
- Author
- Kamo
- Commit
- 19d1119
handleFormSubmit checked the *** and advanced the step — it made no network call at all, so the contact details a visitor typed were only ever persisted if they went on to complete a booking. With no timeslots published yet, that meant none of them were. Step 1 now POSTs to /api/webinar/demo-request. The call is deliberately non-blocking: a failure there must not trap the visitor on step 1, and booking on step 2 writes the lead too (matched back onto the same one, not duplicated). Also fixes the scheduling step, which could not have worked once timeslots did exist: - WEBINAR_TYPE_ID was the literal "1" against routes that take the type's UUID, so every scheduling request 400'd. The id now comes from GET /api/webinar/types. - The responses are enveloped ({webinars}, {availableTimes}), not bare arrays, so both lists parsed as empty and rendered the "nothing available" state regardless of what the backend returned.