SpiderPublish treats forms and booking flows as first-class entities, not plugins. Both share the same underlying model — a booking_flows row in PostgreSQL with a kind discriminator — but serve fundamentally different user experiences.
The Unified Model
A form with kind=form is a standard lead capture: name, email, phone, message, custom fields. A form with kind=booking adds date/time selection, staff assignment, and availability checking. Both render at /f/{id} and use the same submission pipeline.
Real-Time Availability
For booking flows, availability is checked in real-time against connected calendars. The system fetches available slots from all assigned staff calendars via OAuth, deduplicates conflicts, and presents the merged availability grid on every page load.
Concurrency Control
When two visitors attempt to book the same slot simultaneously, optimistic locking with a version column ensures the first submission wins. The second receives a conflict response. We chose optimistic over pessimistic locking because booking conflicts are rare — typically less than 0.1% of submissions.
Webhook Delivery
Every form submission triggers configurable webhooks with at-least-once delivery. Failed deliveries are retried with exponential backoff up to five times over 24 hours. After five failures, the webhook is marked as dead and the tenant receives a notification.
The Question Pipeline
Form questions support conditional logic and variable interpolation. Questions can be shown or hidden based on previous answers, and labels can include merge tags from IDAP records. Logic evaluates client-side for instant feedback, then re-validates server-side on submission.