LanesLanes
Use cases/Lanes Forms/Route submissions to email, Supabase, or webhooks

Route submissions to email, Supabase, or webhooks

Send submissions where you work: email and Lanes-hosted storage today, with webhook and Supabase delivery on the roadmap.

A form is only useful if the data reaches you. Lanes Forms stores every submission and can route it to the destinations you already use.

Delivery is configured per form as a list of workflow actions, set at provisioning and changeable afterwards. Two actions are live today, email forwarding and Lanes-hosted storage, and two are on the roadmap, webhook delivery and custom stores such as Supabase. The delivery table lives in integrating.

Destinations

  • Email. Add recipients and each submission is forwarded to your inbox. Live today. A form forwards to up to 5 recipients; a new address gets a confirmation link and is silently skipped until it verifies, so unverified inboxes never receive mail. Spam is not forwarded.
  • Stored in Lanes. Kept for you with CSV export, even when you route elsewhere. Live today. Submissions are listed in the dashboard, and the submissions endpoint exports them with ?format=csv. See the API reference.
  • Webhooks. Post to your own endpoint and handle it however you like. On the roadmap. Enabling the action today returns 422 action_not_available.
  • Supabase. Write submissions straight into your own database. On the roadmap as a custom store, with the same 422 action_not_available response until it ships.
Webhook and custom-store delivery are not live yet. Enabling either returns 422 action_not_available, a stable code documented in errors, so the gap is explicit rather than silent. Ship with email plus Lanes storage now and flip the workflow when the actions land; the submission contract does not change.

Whatever the destination, the record is the same. Each stored submission keeps the schema fields under data, unknown keys under extra, the request origin, a salted hash of the IP (the raw IP is never stored), a truncated user agent, and a spam score. The full storage story is in submitting.

Set once, change anytime

Update a form's routing with a single PATCH. No redeploy of your site, no code change.

PATCH /v1/forms/{form_id} updates the workflow, recipients, origins, and schema on a claimed form. Authorize it with a workspace API key, prefixed lfk_, shown once at creation and valid for every form in its workspace, or act as the signed-in owner in the dashboard. See API keys.

Set it up

  1. Send a test submission. Anything can POST to the endpoint; API callers get a JSON receipt with a submission id back. See submitting.
Bash
curl -X POST https://api.lanes.sh/v1/f/YOUR_FORM_ID \
  -H "Content-Type: application/json" \
  -d '{"email": "visitor@site.com", "message": "Hello"}'
  1. Add and verify recipients. Each address confirms through an emailed link before it receives anything, and a verification email can be resent from the API or the dashboard. When you claim a form that had recipients, the first one is verified for you. See integrating.
  2. Read or export. Watch submissions arrive in the dashboard, and pull CSV with ?format=csv when you want the data in a spreadsheet or a script.
  3. Adjust routing later. Change the workflow with a PATCH, using your lfk_ key as a bearer token, without touching the page that posts to the form.

Further reading

  • Integrating a form: the delivery table and how email verification works.
  • Submitting data: what each stored submission contains.
  • Errors: the stable error envelope, including action_not_available.
  • API keys: workspace keys for changing routing programmatically.

See Lanes Forms or read the API reference.