LanesLanes
Use cases/Lanes Forms/Booking and inquiry request forms

Booking and inquiry request forms

Capture booking and inquiry requests on any site, route them where your team works, and keep spam out.

Booking and inquiry forms are contact forms with intent: someone wants a slot, a quote, or a callback. Lanes Forms captures the request and routes it wherever your team works.

The endpoint accepts JSON, form-urlencoded, and multipart posts, so it serves a plain HTML form and a custom widget equally well. A browser post redirects the visitor to a hosted thank-you page; an API caller gets a JSON receipt with a submission id. The contract is in submitting.

How Lanes Forms does it

  • Fields that fit. Provision the exact fields you need, from dates to service type. Mark the ones that matter as required: a request that omits them is refused with 422 missing_required_fields, and the response lists exactly which fields were empty, so half-filled requests never reach your calendar.
  • Route the request. Email it to your team, push to a webhook, or store it in Supabase. Email forwarding and Lanes-hosted storage are live today, and a form forwards to up to 5 verified recipients, enough for a whole front desk. Webhook and Supabase delivery are on the roadmap and return 422 action_not_available until they ship. See integrating.
  • Origin-locked. Only your site can submit, so the endpoint cannot be scraped and spammed. Browser posts must come from a hostname in the form's allowed_origins or they get 403 origin_not_allowed. The error even names the origin it received and the allowlist it expected, which makes misconfigurations short-lived. See securing your endpoints.
  • No backend. Nothing to run for a form that just needs to reach a person. The hidden _gotcha honeypot absorbs bots, submissions are rate limited to 10 per minute per IP, and IPs are stored only as salted hashes.

Why it matters

The request lands where you already work, protected from bots, without a server you have to maintain.

An inquiry is also more perishable than a newsletter signup: a request nobody sees for three days is a booking somewhere else. Forwarding to verified inboxes plus a dashboard copy means the request is both delivered and kept.

Set it up

  1. Provision the fields. Create the form with the request fields your team needs, for example email, a preferred date, and a message, with your shared inbox as a recipient. See integrating for the wiring options.
  2. Put the form on the page. A plain HTML form posts straight to the endpoint:
html
<form action="https://api.lanes.sh/v1/f/YOUR_FORM_ID" method="POST">
  <input type="email" name="email" required />
  <input type="text" name="preferred_date" required />
  <textarea name="message"></textarea>
  <!-- honeypot: bots fill this, humans never see it -->
  <input type="text" name="_gotcha" style="display:none" tabindex="-1" />
  <button type="submit">Send</button>
</form>
  1. Claim it and add your team. Claiming turns forwarding on with the first recipient pre-verified; every additional address confirms via an emailed link before it receives requests.
  2. Handle failures explicitly. Every error is a stable machine-readable code in a common envelope, so your page can show a useful message instead of a dead end. See errors.
An inquiry form that fails silently costs real bookings, and the usual causes are a handler that quietly stopped sending mail and a spam filter nobody can see into. Here the default workflow is email plus Lanes storage, so a request is kept even if nobody reads the inbox that day, and spam is marked rather than dropped.

Further reading

See Lanes Forms.