VONDERFILL / DEVELOPER TOOLS

Build your own booking experience

Use your own service cards, layout and customer journey. Vonderfill supplies the published catalog, prices, available appointments and booking/payment engine.

Start with the working example

Copy these four files into one folder on an HTTPS test website. Open index.html, enter the API origin, business slug and public Turnstile site key, then load your designated test business.

Open the reference interface ↗

Before connecting a customer website

  1. Publish the business’s services and intake form in its existing setup tools.
  2. Save the website origin and final return page in Website settings. For this example, use the page containing index.html.
  3. Have Vonderfill register the exact website hostname in the existing Turnstile widget. Use its public site key; never put a secret key in website code. Pilot registration uses the existing free setup.
  4. Verify the complete flow using an isolated test business and Stripe TEST configuration before customer collection.

API v1

Base: https://vonderfill.com/api/v1/public. Use the isolated application’s origin for tests.

ActionEndpointWhat it provides
CatalogGET /{slug}/servicesPublished services, required fields, versioned questions and photo policy.
QuotePOST /{slug}/quoteServer-calculated price and required payment percentage for your selection.
TimesGET /{slug}/availabilityAvailable slots for one core service and selected add-ons.
PhotosPOST /{slug}/intake-uploadsUp to three temporary, scoped upload destinations.
SubmitPOST /{slug}/bookingsRequest outcome and required Checkout URL.
Payment recoveryPOST /booking-return/exchange, state, payBrowser-proof exchange, authoritative status and safe payment retry.

Request fields

Quote accepts { selection }. Selection includes core_service_id, addon_service_ids, optional dimension.class_key or dimension.measure, and quantities keyed by service ID. Choose one core and up to 20 distinct add-ons. Quantities are integers 1–99; measurements are 0–10,000,000 in the published service’s units.

Availability uses service, comma-separated addons, ISO from and to parameters. The maximum range is 60 days. Slots are not reservations.

Booking adds structured client identity (version 2), consent, optional property, details, versioned intake, photo attachments, the chosen requested_start, and a stable idempotency_key. The example shows the complete payload. Custom callers send integration: "custom-v1" and a Turnstile token bound to their hostname and the custom-booking action.

State and recovery

A quote does not reserve time or lock a price. Submission revalidates the catalog and appointment. A successful request is not necessarily a confirmed appointment or a paid booking. Required Checkout must complete, and payment status comes from the server after the signed webhook.

Keep the same idempotency key after a lost response. Refresh expired verification and upload tokens; do not create another booking to recover a payment. The example retains an unresolved submission in this browser’s session storage and removes customer details after success. Do not add analytics to receipt pages.

Errors use ok: false with a stable code. Correct invalid selections/fields (400), renew verification (403), refresh conflicting form/catalog state (409), wait after rate limits (429), and retry an unchanged submission after temporary failures (503). Never assume a network failure means no write.

Supported scope

One published business-wide form, the existing pricing dimensions, and current booking/quote/request tracks. No arbitrary pricing formulas, per-service branching forms, account-admin API or customer exports. Guided Wix field mapping is a separate delivery.

Within v1, additions remain optional for existing callers. Breaking field or state changes require a new version with a documented migration path; existing widget callers remain supported. Examples and documentation carry the same version as their API contract.