Turn Any HTML Form Into a Notion Database — Step by Step with onsubmit.dev (form backend)
If you want a waitlist, feedback form, or lead-capture form to create new rows in Notion without building an API, onsubmit.dev (form backend) can handle the server-side submission for you. Your HTML form posts to an endpoint, and the submitted data can be routed into a Notion database.
This is particularly handy for small sites and static deployments where adding a backend just to process a form feels unnecessary.
What we're building
The flow is simple:
HTML form → onsubmit.dev (form backend) → Notion database
For example, imagine a product waitlist with fields for:
- Name
- Company
- Message
Every successful submission becomes a new row in a Notion database, giving you a lightweight lead list that your team can already view, filter, and organize.
1. Create the Notion database
Start by creating a database in Notion for the submissions.
Add properties matching the information you want to collect. For our example, that might look like:
| Property | Notion type |
|---|---|
| Name | Title |
| Company | Text |
| Message | Text |
The important part is to keep the form fields and your intended Notion properties aligned, so you know exactly where each submitted value should go.
2. Set up the form endpoint
Create your form using onsubmit.dev (form backend), then configure its Notion integration for the database where submissions should be stored.
When connecting Notion, make sure the relevant Notion page/database has been shared with the integration. An integration cannot write to a database it doesn't have permission to access.
Once configured, you get a submission endpoint for the form.
3. Connect your HTML form
Set the form's action to the endpoint generated for your form and use POST as the HTTP method.
For example, your page can collect the four fields described above and send them to that endpoint. Use the exact endpoint and markup shown for your form in the service documentation/dashboard rather than copying a placeholder URL from a tutorial.
The key idea is that the browser submits directly to onsubmit.dev (form backend). You don't need to create an Express route, serverless function, database connection, or custom Notion API handler just to receive the form.
4. Map the fields to Notion
Configure the integration so each submitted form value is written to its corresponding Notion property.
For our waitlist, the mapping is conceptually:
name → Name
email → Email
company → Company
message → Message
Pay attention to Notion property types here. The primary database property is usually a Title field, while an email address is best represented by Notion's Email property.
After saving the integration, submit a test response through the actual form.
5. Check the resulting Notion table
Open the database in Notion after submitting the form. A successful submission should appear as a newly created database row.
Screenshot description: A Notion database displayed in table view with columns named \"Name,\" \"Email,\" \"Company,\" and \"Message.\" Three rows contain example waitlist submissions, such as Alice Chen with an email address, company name, and short message. Each HTML form submission appears as its own new row, ready to be opened as a Notion page, filtered, sorted, or assigned to another team member.
At this point, Notion effectively becomes the destination for your form data.
Where this pattern is useful
A Notion-backed form works especially well when the submitted data is operational rather than application state. Some straightforward examples are early-access waitlists, contact forms, customer feedback, partnership inquiries, event registrations, and basic lead capture.
It also means non-developers can work with incoming submissions using an interface they may already know instead of needing access to an application database.
For more complex applications, you'll probably still want a conventional database and backend. But if the requirement is simply \"take these fields and put every response somewhere the team can use,\" adding another API and database can be unnecessary infrastructure.
That's it
The final architecture stays pleasantly small:
visitor → HTML form → form endpoint → Notion
Your frontend remains a normal HTML form, onsubmit.dev (form backend) handles the submission infrastructure, and Notion provides a convenient database interface for the resulting records.
That makes the same setup easy to reuse the next time a project needs a waitlist, feedback box, or lead form without spinning up a backend solely to process submissions.
