Skip to main content
The quickstart gave you a live form in three steps. This page traces what the platform actually did.

​
Where the YAML comes from

When you push apply.yaml to your repository’s main branch, it becomes accessible at: 
https://raw.githubusercontent.com/{owner}/{repo}/main/apply.yaml
When someone visits https://app.declarativeforms.com/{owner}/{repo}/apply, the API fetches that raw URL and parses the YAML. The form always reflects the current main branch — push a change, refresh the form URL, and the update is live.

​
How the form loads

The browser receives the parsed form definition as JSON and renders the first section. For apply.yaml, that’s three fields:
  • full_name — short_text renders a single-line text input
  • role — single_select renders radio buttons, one per option
  • email — email renders a text input that validates email address format before submission
Field values stay in the browser until the user submits. Validators (if configured) run client-side before the section is sent to the API.

​
How submissions work

When the user submits, the browser sends the field values to the API. The API saves a submission record and returns a submission_id. On the final section — which is the only section in apply.yaml — the submission is marked completed and any configured connections fire.

​
Partial saves

For multi-section forms, the URL gets updated after each section: 
https://app.declarativeforms.com/{owner}/{repo}/apply?submission_id=abc123&step=next_section
This URL can be bookmarked or shared. When revisited, the browser resumes from the saved step with previously entered data pre-populated. apply.yaml has one section, so this doesn’t apply yet — but it matters once you start building multi-section flows. See Sections for how navigation between sections works.
Ready to understand the full schema? Start with YAML Schema, then dive into the Concepts section for each piece.