Surveys

A survey is a form rendered one question at a time. Same builder, same submission inbox — different public renderer, plus three things classic forms don't have:

• Branching. Send respondents down different paths based on what they answered.
• Scoring & outcomes. Tally points per answer; resolve a named outcome at the end.
• Resume. A respondent can close the tab and pick up where they left off.

Switch a form into survey mode from the Mode toggle in the builder. Existing fields keep working; new field types (rating, NPS, scale, ranking, picture choice, signature) become available.

Public URL

A published survey lives at /s/{public_id}. The classic /f/{public_id} POST endpoint still exists but isn't used by the survey renderer — finalization happens via /s/{public_id}/complete, which then materializes a real submission in your inbox just like any other form.

What you keep

Webhooks, automations, autoresponder, AI moderation, retention, exports — everything that fires for a classic submission also fires for a completed survey response. Nothing in your downstream pipeline cares whether the data came from a <form> POST or a guided survey.

In-flight buffers

While a respondent is answering, their partial state lives in a separate buffer table — not the submissions table. Buffers are pruned by the same retention sweep that prunes old submissions. Once they hit Submit, the buffer becomes a real submission and the link sticks around so you can audit the path they took.