Since Formium is an API-first service, there are quite a few ways to gather responses (which we call submissions) to a single form. This guide we'll help you figure out which is right for your specific form and project.
Every form on Formium is hosted at a unique URL on forms.formium.io. You can find your form's hosted URL by either going to its Overview panel and looking at the Share your form card or by pressing the View button on the top right of the screen on any other panel (aside from the Editor). Hosted forms work exactly like forms on other traditional form building services you may have used such as Google Forms or Survey Monkey or TypeForm. The user experience is as follows:
- You send your users to the form's URL (i.e. forms.formium.io/f/xxxxx).
- Users fill out and submit the form
- Responses are immediately stored on Formium (and are viewable in the Dashboard on the Results panel)
Now for the fun part...
Instead of sending your users to https://forms.formium.io/f/xxxxx to fill out the form, you can keep them in your application or website by using Formium's API and helper libraries directly. And no, we're not talking about using an
iframe like it's 2008, but instead using your very own code to render the form for yourself. Don't worry, this isn't as scary as it sounds.
How It Works
When you build a form on Formium with the drag-and-drop editor, you're not really building a form. You're actually generating an abstract data structure (a.k.a "schema") that represents your form. This big blob of data is an architectural blueprint that contains all the text, all the choices, all the conditional logic, all the itty-bitty details of your form. With our API, you can then use your form schemas in your application/website to natively render your forms as if they were hand-coded, using whatever programming language or framework you want to.
If this sounds like a lot, it totally is. However, unlike other "headless" CMS tools you may have used, we actually know exactly what you're going to do: You're going to render a form! It's going to have some inputs! It's probably going to have a submit button! So knowing all this and some more, we saved you a boat load of time and energy and built helper libraries to take care of the heavy lifting of fetching and interpreting your schemas and submitting responses. In fact, we actually use all of these packages on forms.formium.io to power all the "hosted" forms. So, in reality, when you make a hosted form, you're actually just making another headless form, but we're doing the headless stuff for you with our code. You're welcome.
Developer Stuff Lies Ahead...
Let's chat briefly about a few common "headless" architectures.
For security reasons, you form's schema isn't available on the public interwebz and requires an API key to access it. This constraint means you are going to need to fetch your form schema from the Formium API from a secure server-side environment at some point in your workflow.
Unfortunately, this next part is a bit of a "choose-your-own-adventure" situation. Where and when you fetch your schemas can differ greatly depending on the form, what frontend framework you use, how often your form updates, how long your app or site takes to rebuild, your hosting provider, your CI service, and your own personal preferences. To make things even more combinatorial (is that a even word?), not all hosting providers are created equal these days. Some providers such as Vercel can do special incremental static page regeneration for their Next.js framework that merges the concept of runtime and buildtime together, while other providers such as Netlify do not support the same features.
Anyways, there are a bunch of options here, but we think it ultimately boils down to whether you want to (or need to) fetch your form schema at runtime (per request) or buildtime (per deployment/build).
Fetch Schemas at Runtime
This strategy works by fetching your form's schema on every request from a server or serverless function. It's useful for apps that have have a LOT of forms where downloading all the schemas at once isn't possible. Or, for forms that need changes to be reflected immediately (like on the very next request). For example, forms.formium.io (the app that serves up the 15 quadrillion hosted forms on the platform) fetches your form schema at runtime because it would take an insanely long time to regenerate a static page for every form on everytime some users makes a change.
Fetch Schemas at Buildtime
The other approach is to fetch all your schemas during a build step and then trigger a full site rebuild whenever a change is made to a form in the Formium dashboard (using Formium's HTTP Webhook Workflow). The nice thing about this workflow is that your form schemas are immutable between deployments of your app, which makes debugging easier for in-app forms that rely on other code or app state.
Again, your specific workflow is going to depend your app or website.